Re: [PATCH 1/6] drm: Add helper to check exporting driver of a DMA-buf

Am 06.07.2017 um 22:16 schrieb Felix Kuehling: This allows drivers to check if a DMA-buf contains a GEM object and whether it comes from the same driver. It may be from the same or a different device. Signed-off-by: Felix Kuehling I think Daniel/Dave hadmore a

[PATCH 11/22] drm/atomic: Convert private_objs to drm_dynarray

From: Ville Syrjälä state->private_objs grows dynamically, so switch it over to use the new drm_dynarray helper. Cc: Dhinakaran Pandiyan Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c

[PATCH 17/22] drm/atomic: Fix up the kernel docs for the state duplication functions

From: Ville Syrjälä Coccinelle doesn't fix up the docs for us, so let's do it manually. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic_helper.c | 12 +--- include/drm/drm_connector.h | 2 +-

[PATCH 16/22] drm/atomic: Pass old state explicitly to .atomic_duplicate_state()

From: Ville Syrjälä We'll be wanting to duplicate other states besides the one pointed to by crtc->state & co., so pass the duplicated state in explicitly. I wanted to make the old_state const, but that would have results in tons of new warnings because some

[PATCH 12/22] drm/atomic: Make private objs proper objects

From: Ville Syrjälä Make the atomic private object stuff less special by introducing proper base classes for the object and its state. Drivers can embed these in their own appropriate objects, after which these things will work exactly like the plane/crtc/connector

[PATCH 10/22] drm/atomic: Remove pointless private object NULL state check

From: Ville Syrjälä We will never add private objects with a NULL state into the atomic state, hence checking for that is pointless. Cc: Dhinakaran Pandiyan Reviewed-by: Daniel Vetter Signed-off-by: Ville

[PATCH 13/22] drm/atomic: Pass old state to __drm_atomic_helper_crtc_duplicate_state() & co. explicitly

From: Ville Syrjälä We'll be wanting to duplicate other states besides the one pointed to by crtc->state & co., so pass the duplicated state in explicitly. @r@ identifier F =~ "^__drm_atomic_helper_.*_duplicate_state$"; identifier O, S; type T, TS; @@ F(T O, TS *S

[PATCH 09/22] drm/atomic: Convert state->connectors to drm_dynarray

From: Ville Syrjälä state->connectors[] can grows dynamically, so we can switch over to using the new drm_dynarray. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 49 +++--

[PATCH 15/22] drm/mediatek: s/old_state/old_mtk_state/

From: Ville Syrjälä Rename the local 'old_state' variable to 'old_mtk_state' to get it out of the way of some cocci refactoring. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/mediatek/mtk_drm_plane.c | 4 ++-- 1 file changed, 2

[PATCH 20/22] drm/i915: Refactor __intel_atomic_commit_tail()

From: Ville Syrjälä Split intel_atomic_commit_tail() into a lower level function that does the actual commit, and a higher level one that waits for the dependencies and signals the commit as done. We'll reuse the lower level function to perform commits during GPU

[Bug 196273] Loss of video output and system freezes *ERROR* Couldn't read SADs: 0

https://bugzilla.kernel.org/show_bug.cgi?id=196273 --- Comment #8 from Olaf H B (o...@seldiame.net) --- (In reply to Michel Dänzer from comment #6) > Is this a regression from older kernel versions? If yes, can you bisect? I don't think this is a regression because I had similar issues with

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 06, 2017 at 11:22:43AM -0700, Keith Packard wrote: > Ville Syrjälä writes: > > > I was mostly thinking of the 'seq = query(); wait(seq + n);' pattern > > where we can avoid doing the full update more than once if we enable > > the interrupt already

[Bug 196273] Loss of video output and system freezes *ERROR* Couldn't read SADs: 0

https://bugzilla.kernel.org/show_bug.cgi?id=196273 --- Comment #10 from Alex Deucher (alexdeuc...@gmail.com) --- Can you get a log with symbols? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing

[PATCH v2 00/22] drm/i915: Fix pre-g4x GPU reset, again (v2)

From: Ville Syrjälä OK, so here's the full version of my rw_semaphore GPU vs. display reset fix. The only issue I'm aware of is that SKL watermark code still uses obj->state and thus I have no clue what would happen if one tries to run this on SKL. Untangling that

[PATCH 04/22] drm/i915: Pass proper old/new states to intel_plane_atomic_check_with_state()

From: Ville Syrjälä Eliminate plane->state and crtc->state usage from intel_plane_atomic_check_with_state() and its callers. Instead pass the proper states in or dig them up from the top level atomic state. Note that intel_plane_atomic_check_with_state() itself

[PATCH 02/22] drm/i915: Pass the crtc state explicitly to intel_pipe_update_start/end()

From: Ville Syrjälä Pass the appropriate new crtc state explicitly to intel_pipe_update_start/end() instead of of mucking around with crtc->state. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 18

[PATCH 05/22] drm/i915: Eliminate obj->state usage from pre/post plane update

From: Ville Syrjälä Dig up the appropriate new crtc and plane states from the top level atomic state in intel_pre_plane_update() and intel_post_plane_update(). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c |

[PATCH 08/22] drm: Add drm_dynarray

From: Ville Syrjälä Add a small helper that gives us dynamically growing arrays. We have a couple hand rolled implementations of this in the atomic code, which we can unify to use a common implementation. Signed-off-by: Ville Syrjälä

[PATCH 07/22] drm/i915: Eliminate crtc->state usage from intel_atomic_commit_tail and .crtc_update()

From: Ville Syrjälä We already have the correct new crtc state so just use that instead of crtc->state. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH 06/22] drm/i915: Eliminate crtc->state usage from intel_update_pipe_config()

From: Ville Syrjälä Pass the correct new crtc state to intel_update_pipe_config() instead of using crtc->state. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 19 +-- 1 file changed, 9

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Ville Syrjälä writes: > With the disable_immediate thing we only wait until the next vblank > before disabling the irq again. Ok, still sounds like we'll be doing fine if the application does a get immediately followed by a queue event. At least most of the time.

[PATCH v3 21/22] drm/atomic: Introduce drm_atomic_helper_duplicate_commited_state()

From: Ville Syrjälä For i915 GPU reset handling we'll want to be able to duplicate the state that was last commited to the hardware. For that purpose let's start to track the commited state for each object and provide a way to duplicate the commmited state into a

[PATCH 18/22] drm: Return the connector from drm_connector_get()

From: Ville Syrjälä Make drm_connector_get() return the connector. This allows the nice pattern of 'foo->connector = drm_connector_get(connector)' Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_atomic.c| 3 +--

[PATCH 14/22] drm/arm: s/old_state/old_mali_state/

From: Ville Syrjälä Rename the local 'old_state' variable to 'old_mali_state' to get it out of the way of some cocci refactoring. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/arm/malidp_crtc.c | 10 +- 1 file changed, 5

[PATCH v5 22/22] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore

From: Ville Syrjälä Introduce an rw_semaphore to protect the display commits. All normal commits use down_read() and hence can proceed in parallel, but GPU reset will use down_write() making sure no other commits are in progress when we have to pull the plug on the

[PATCH 19/22] drm/i915% Store vma gtt offset in plane state

From: Ville Syrjälä To avoid having to deference plane_state->vma during the commit phase of plane updates, let's store the vma gtt offset (or the bus address when we need it) in the plane state. This is crucial for doing the modeset operations during GPU reset as

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Ville Syrjälä writes: > I was mostly thinking of the 'seq = query(); wait(seq + n);' pattern > where we can avoid doing the full update more than once if we enable > the interrupt already during the query. Don't we still wait 5 seconds before disabling vblank? In

[Bug 99859] Glamor Crashes on big endian Hardware

https://bugs.freedesktop.org/show_bug.cgi?id=99859 --- Comment #22 from intermedi...@hotmail.com --- last mesa xorg log just to report. different error. with last mesa dev OpenGL core profile version string: 3.3 (Core Profile) Mesa 17.2.0-devel (git-f78aa2c986) [

[PATCH 01/22] drm/i915: Pass the new crtc state to color management code

From: Ville Syrjälä In an effort to eliminate the obj->state usage let's pass on the new crtc state pointer (which we already have!) to the color management code. Signed-off-by: Ville Syrjälä ---

[PATCH 03/22] drm/i915: Eliminate obj->state usage in g4x/vlv/chv wm computation

From: Ville Syrjälä Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 9 + drivers/gpu/drm/i915/intel_drv.h | 8 drivers/gpu/drm/i915/intel_pm.c | 30 +++--- 3 files

[PATCH v2 4/4] drm/i915: Acquire PUNIT->PMIC bus for intel_uncore_forcewake_reset()

intel_uncore_forcewake_reset() does forcewake puts and gets as such we need to make sure that no-one tries to access the PUNIT->PMIC bus (on systems where this bus is shared) while it runs, otherwise bad things happen. Normally this is taken care of by the i915_pmic_bus_access_notifier() which

[PATCH v2 1/4] drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier

assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier even though it gets unregistered on (runtime) suspend, this is caused by a race happening under the following circumstances: intel_runtime_pm_put does: atomic_dec(_priv->pm.wakeref_count);

[Bug 196273] Loss of video output and system freezes *ERROR* Couldn't read SADs: 0

https://bugzilla.kernel.org/show_bug.cgi?id=196273 --- Comment #9 from Olaf H B (o...@seldiame.net) --- Created attachment 257391 --> https://bugzilla.kernel.org/attachment.cgi?id=257391=edit kern.log -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH 1/6] drm: Add helper to check exporting driver of a DMA-buf

This allows drivers to check if a DMA-buf contains a GEM object and whether it comes from the same driver. It may be from the same or a different device. Signed-off-by: Felix Kuehling --- drivers/gpu/drm/drm_prime.c | 24 include/drm/drmP.h

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 6, 2017 at 6:27 PM, Keith Packard wrote: > Daniel Vetter writes: > >> I very much like this since the old ioctl really is a rather bad horror >> show. And since it's tied in with ums drivers everything is >> complicated. > > Thanks for your kind

Re: [PATCH libdrm] libdrm_amdgpu: add kernel semaphore support

Chrstian, you are probably the best person to ack this, I'd like to get the radv code landed and allow the GL code to get going. Dave. > This adds kernel semaphore support to the command submission > interface in what should be a backwards compatible manner, > it adds a new command submission

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

On Wed, Jul 05, 2017 at 03:10:11PM -0700, Keith Packard wrote: > This modifies the datatypes used by the vblank code to provide both 64 > bits of vblank count and to increase the resolution of the vblank > timestamp from microseconds to nanoseconds. > > The driver interfaces have also been

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

On 06/07/17 07:10 AM, Keith Packard wrote: > This modifies the datatypes used by the vblank code to provide both 64 > bits of vblank count and to increase the resolution of the vblank > timestamp from microseconds to nanoseconds. > > The driver interfaces have also been changed to return 64-bits

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

On 06/07/17 04:45 PM, Michel Dänzer wrote: > On 06/07/17 07:10 AM, Keith Packard wrote: >> This modifies the datatypes used by the vblank code to provide both 64 >> bits of vblank count and to increase the resolution of the vblank >> timestamp from microseconds to nanoseconds. >> >> The driver

Re: [PATCH v3 05/16] drm/fb-helper: do a generic fb_setcmap helper in terms of crtc .gamma_set

> >> @@ -1369,27 +1362,57 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, > >> struct fb_info *info) > >>memcpy(g + cmap->start, cmap->green, cmap->len * sizeof(*g)); > >>memcpy(b + cmap->start, cmap->blue, cmap->len * sizeof(*b)); > >> > >> - for (j = 0; j <

Re: [PATCH 2/3] drm: Reorganize drm_pending_event to support future event types

On Wed, Jul 05, 2017 at 03:10:12PM -0700, Keith Packard wrote: > Place drm_event_vblank in a new union that includes that and a bare > drm_event structure. This will allow new members of that union to be > added in the future without changing code related to the existing vbl > event type. > >

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Wed, Jul 05, 2017 at 03:10:13PM -0700, Keith Packard wrote: > These provide crtc-id based functions instead of pipe-number, while > also offering higher resolution time (ns) and wider frame count (64) > as required by the Vulkan API. > > Signed-off-by: Keith Packard I very

Re: [PATCH 12/14] drm/exynos: mic: clean up drm_bridge_add call

On 07/05/2017 04:42 PM, Emil Velikov wrote: On 5 July 2017 at 10:14, Archit Taneja wrote: On 07/05/2017 02:35 PM, Inki Dae wrote: 2017년 07월 05일 18:00에 Archit Taneja 이(가) 쓴 글: On 07/03/2017 02:12 PM, Inki Dae wrote: This patch removes unnecessary checking

Re: [PATCH v3 03/16] drm/fb-helper: remove drm_fb_helper_save_lut_atomic

On Tue, Jul 04, 2017 at 12:36:59PM +0200, Peter Rosin wrote: > drm_fb_helper_save_lut_atomic is redundant since the .gamma_store is > now always kept up to date by drm_fb_helper_setcmap. > > Signed-off-by: Peter Rosin Merged up to this patch to drm-misc-next, thanks. Pleas base

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 6, 2017 at 12:16 PM, Ville Syrjälä wrote: >> > + if (!dev->irq_enabled) >> > + return -EINVAL; >> > + >> > + crtc = drm_crtc_find(dev, get_seq->crtc_id); >> > + if (!crtc) >> > + return -ENOENT; >> > + >> > + pipe =

Re: [PATCH 00/14] clean up drm_bridge_add

On 07/03/2017 02:12 PM, Inki Dae wrote: This patch series changes return type of drm_bridge_add function to void one and also removes unnecessary checking of the return type from relevant drivers. Ps. I had just build test so each maintainer may need to check this. I pushed all the bridge

Re: [PATCH libdrm 2/2] radeon: use asic id table to get chipset name

On 5 July 2017 at 22:31, Li, Samuel wrote: >> - above all, as-is make check will fail > Right, I did not check that. > >> - keeping the radeon API symmetrical to the amdgpu one would a good idea > The issue is Radeon does not have a struct similar to amdgpu_device_handle.

[PATCH][drm-next] drm/amdgpu: make arrays pctl0_data and pctl1_data static

From: Colin Ian King The arrays pctl0_data and pctl1_data do not need to be in global scope, so them both static. Cleans up sparse warnings: symbol 'pctl0_data' was not declared. Should it be static? symbol 'pctl1_data' was not declared. Should it be static?

[PATCH] drm/bridge: dw_hdmi: add cec notifier support

From: Russell King Add CEC notifier support to the HDMI bridge driver, so that the CEC part of the IP can receive its physical address. Tested-by: Neil Armstrong Acked-by: Neil Armstrong Acked-by: Hans Verkuil

Re: [PATCH] drm/bridge: dw_hdmi: add cec notifier support

On 07/06/2017 01:05 PM, Russell King - ARM Linux wrote: > On Thu, Jul 06, 2017 at 12:33:06PM +0200, Neil Armstrong wrote: >> From: Russell King >> >> Add CEC notifier support to the HDMI bridge driver, so that the CEC >> part of the IP can receive its physical address.

Re: [Intel-gfx] [PATCH] drm/crc: Handle opening and closing crc better

Looks good to me: Reviewed-by: Tomeu Vizoso I guess you have tested this with IGT? In any case, I think it would be good to mention how a patch has been tested in the changelog. That can be very useful to others if things go wrong at some point. Thanks, Tomeu

Re: [PATCH] drm/bridge: dw_hdmi: add cec notifier support

On 07/06/2017 12:43 PM, Jose Abreu wrote: > Hi Neil, > > > On 06-07-2017 11:33, Neil Armstrong wrote: >> From: Russell King >> >> Add CEC notifier support to the HDMI bridge driver, so that the CEC >> part of the IP can receive its physical address. >> >> Tested-by:

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 06, 2017 at 09:53:13AM +0200, Daniel Vetter wrote: > On Wed, Jul 05, 2017 at 03:10:13PM -0700, Keith Packard wrote: > > These provide crtc-id based functions instead of pipe-number, while > > also offering higher resolution time (ns) and wider frame count (64) > > as required by the

Re: [PATCH] drm/bridge: dw_hdmi: add cec notifier support

topped working as its stuck with a physical > address of f.f.f.f) so I think the whole thing is rather moot right > now. I don't yet know what's going on with that, other than the > notifier stuff seems to not be working, despite being enabled in > the .config. > Indeed, I missed some parts of the thread, sorry for the confusion. Anyway, is it a showstopper to have this patch merged separately ? If you prefer re-posting a serie with this patch inside, no problem, but the Amlogic platform still needs this patch to have CEC working. Maybe it's because of fixes introduced in 4.13, but using next-20170706 and this patch, make things works perfectly. Neil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/crc: Only open CRC on atomic drivers when the CRTC is active.

Op 06-07-17 om 13:09 schreef Tomeu Vizoso: > Looks good to me: > > Reviewed-by: Tomeu Vizoso > > I guess you have tested this with IGT? In any case, I think it would > be good to mention how a patch has been tested in the changelog. That > can be very useful to others

RE: [PATCH libdrm 2/2] radeon: use asic id table to get chipset name

> -Original Message- > From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf > Of Emil Velikov > Sent: Thursday, July 06, 2017 5:21 AM > To: Li, Samuel > Cc: ML dri-devel; amd-gfx mailing list > Subject: Re: [PATCH libdrm 2/2] radeon: use asic id table to get chipset name

[PATCH 2/5] drm/i915: Protect against deferred fbdev setup

We could probably hit this already with our current async fbdev init, but it's much easier to hit this with the new deferred fbdev setup that I'm working on polishing. Cc: Maarten Lankhorst Reported-by: Maarten Lankhorst

[PATCH 5/5] drm/hisilicon: Remove custom FB helper deferred setup

From: Thierry Reding The FB helper core now supports deferred setup, so the driver's custom implementation can be removed. v2: Dont' resurrect drm_vblank_cleanup. Cc: Xinliang Liu Cc: Rongrong Zou Cc: Xinwei Kong

[PATCH 4/5] drm/exynos: Remove custom FB helper deferred setup

From: Thierry Reding The FB helper core now supports deferred setup, so the driver's custom implementation can be removed. v2: Drop NULL check, drm_fb_helper_hotplug_event handles that already. Cc: Inki Dae Cc: Joonyoung Shim

[PATCH 1/5] drm/i915/fbdev: Always forward hotplug events

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 this check was added in commit c45eb4fed12d278d3619f1904885bd0d7bcbf036 (tag: drm-intel-next-fixes-2016-08-05) Author: Chris Wilson

[PATCH 3/5] drm/fb-helper: Support deferred setup

FB helper code falls back to a 1024x768 mode if no outputs are connected or don't report back any modes upon initialization. This can be annoying because outputs that are added to FB helper later on can't be used with FB helper if they don't support a matching mode. The fallback is in place

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

On Thu, Jul 06, 2017 at 01:04:18PM +0200, Daniel Vetter wrote: > On Thu, Jul 6, 2017 at 12:16 PM, Ville Syrjälä > wrote: > >> > + if (!dev->irq_enabled) > >> > + return -EINVAL; > >> > + > >> > + crtc = drm_crtc_find(dev, get_seq->crtc_id); > >> > +

Re: [PATCH][drm-next] drm/amdgpu: make arrays pctl0_data and pctl1_data static

On Thu, Jul 6, 2017 at 5:58 AM, Colin King wrote: > From: Colin Ian King > > The arrays pctl0_data and pctl1_data do not need to be in global scope, > so them both static. > > Cleans up sparse warnings: > symbol 'pctl0_data' was not declared.

[RESEND GIT PULL] mediatek drm next for 4.13

Hi, Dave: This include new color format support and some fixups. Please kindly let me know if there is any problem. Regards, CK The following changes since commit 6d61e70ccc21606ffb8a0a03bd3aba24f659502b: Backmerge tag 'v4.12-rc7' into drm-next (2017-06-27 08:28:30 +1000) are available in

Re: [PATCH v1 2/3] dt-bindings: display: panel: Add support for Orise Tech otm8009a dsi panel

On 07/04/2017 06:30 PM, Philippe CORNU wrote: > The Orise Tech OTM8009A is a 3.97" 480x800 TFT LCD panel connected using > a MIPI-DSI video interface. Its backlight is managed through the DSI link. > > Signed-off-by: Philippe CORNU > --- >

xilinx_drm vblank from VDMA callback

> On Jul 5, 2017, at 18:56, Hyun Kwon wrote: > > For VDMA, I think you can use the DMA engine complete callback to generate > the vblank. > > But, please note that it's not a global solution, and it doesn't work for > some other pipelines. For example, the ZU+ DPDMA

[PATCH 0/4] Make fbcon a built-time depency for fbdev, take 2

Hi all, So the original simple hack failed and we need to do a bit more. This time tested including depmod for all combos. And since I had the pleasure to read more fbdev code, 3 simple patches on top to clean up some more. Cheers, Daniel Daniel Vetter (4): fbcon: Make fbcon a built-time

[PATCH 1/4] fbcon: Make fbcon a built-time depency for fbdev

There's a bunch of folks who're trying to make printk less contended and faster, but there's a problem: printk uses the console_lock, and the console lock has become the BKL for all things fbdev/fbcon, which in turn pulled in half the drm subsystem under that lock. That's awkward. There reasons

[PATCH 2/4] fbdev: Nuke FBINFO_MODULE

Instead check info->ops->owner, which amounts to the same. Spotted because I want to remove the pile of broken and cargo-culted fb_info->flags assignments in drm drivers. Cc: Bartlomiej Zolnierkiewicz Cc: linux-fb...@vger.kernel.org Signed-off-by: Daniel Vetter

[PATCH 4/4] drm/: Drop fbdev info flags

- FBINFO_CAN_FORCE_OUTPUT has been a lie ever since we nerfed the entire panic handling code in our fbdev emulation. We might restore kms panic output, but not through the bazillion of legacy code layers called fbdev/fbcon, there's just no way to make that work safely. - With the module

[PATCH 3/4] drm/qxl: Drop fbdev hwaccel flags

It's not accelarated, just system memory. Note we don't even need to set the default flag since that's now always 0. Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualizat...@lists.linux-foundation.org Signed-off-by: Daniel Vetter ---

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

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 this check was added in > > commit c45eb4fed12d278d3619f1904885bd0d7bcbf036

[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880

https://bugs.freedesktop.org/show_bug.cgi?id=99801 --- Comment #13 from Matthew Treinish --- I was wondering if there was any update on this? I'm still seeing the same issue on a 4.11.7 kernel. I'm willing to test out any patches or provide any additional debug info that is

[Bug 194761] amdgpu driver breaks on Oland (SI)

https://bugzilla.kernel.org/show_bug.cgi?id=194761 Alexander Tsoy (alexan...@tsoy.me) changed: What|Removed |Added CC||alexan...@tsoy.me

Re: [PATCH 2/3] drm: Reorganize drm_pending_event to support future event types

Daniel Vetter writes: > A few nits below, but looks good otherwise. Thanks. >> static struct drm_pending_vblank_event *create_vblank_event( >> -struct drm_device *dev, uint64_t user_data) >> +struct drm_device *dev, struct drm_crtc *crtc, uint64_t >>

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

Michel Dänzer writes: > Subtle breakage here: vblwait->request.sequence must still get updated > for _DRM_VBLANK_RELATIVE, in case we're interrupted by a signal. Thanks for finding this. I think it might be better to just not modify the request.type field instead, so that

Re: [PATCH v1 3/3] drm/panel: Add support for otm8009a panel driver

On 07/05/2017 11:28 AM, Andrzej Hajda wrote: > On 04.07.2017 18:30, Philippe CORNU wrote: >> This patch adds Orise Tech otm8009a 3.97" 480x800 TFT LCD >> panel driver (MIPI-DSI video mode). The panel backlight is >> managed through the DSI link. This panel driver is used in >> several STM32

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

Daniel Vetter writes: > Extending the reported/sw vblank counter to u64 makes sense imo, but do we > have to extend the driver interfaces too? If there's no 64 bit hw vblank > currently I think I'd be good to postpone that part, simply because I'm > too lazy to audit all the

Re: [PATCH 1/3] drm: Widen vblank count to 64 bits. Change vblank time precision to ns

Michel Dänzer writes: > BTW, this got me thinking that we should probably treat > _DRM_VBLANK_NEXTONMISS the same way, i.e. clear the flag after updating > vblwait->request.sequence. Otherwise there could theoretically (though > unlikely) be an infinite loop: I was thinking

[Bug 194761] amdgpu driver breaks on Oland (SI)

https://bugzilla.kernel.org/show_bug.cgi?id=194761 --- Comment #71 from Alexander Tsoy (alexan...@tsoy.me) --- (In reply to Alexander Tsoy from comment #70) > For me P4_8x16 config fixed this issue. > > $ sudo dmesg | egrep 'RAM width|OLAND' > [1.670667] [drm] initializing kernel modesetting

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Daniel Vetter writes: > I very much like this since the old ioctl really is a rather bad horror > show. And since it's tied in with ums drivers everything is > complicated. Thanks for your kind words. > I started a discussion a while back whether these should be restricted to

Re: [PATCH 3/3] drm: Add CRTC_GET_SEQUENCE and CRTC_QUEUE_SEQUENCE ioctls

Ville Syrjälä writes: > Maybe, or maybe we want to turn the interrupt on in that case? That's > what the old ioctl does. That's what I suggested in my reply to Daniel's review. Even if we add the accurate function, we'll still need the interrupt-enable case as a

[PATCH 02/15] drm/edid: complete CEA modedb(VIC 1-107)

CEA-861-F specs defines new video modes to be used with HDMI 2.0 EDIDs. The VIC range has been extended from 1-64 to 1-107. Our existing CEA modedb contains only 64 modes (VIC=1 to VIC=64). Now to be able to parse new CEA modes using the existing methods, we have to complete the modedb (VIC=65

[PATCH 01/15] drm: handle HDMI 2.0 VICs in AVI info-frames

HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64). For any other mode, the VIC filed in AVI infoframes should be 0. HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is extended to (VIC 1-107). This patch adds a bool input variable, which indicates if

[PATCH 03/15] drm/edid: parse sink information before CEA blocks

CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. This block contains a map of indexes of CEA modes, which can support YCBCR 420 output also. To avoid multiple parsing of same CEA block, let's parse the sink information and get this map, before parsing CEA modes. This patch moves the

[PATCH 00/15] YCBCR 4:2:0 handling in DRM layer

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 than YCBCR 4:4:4 or RGB 8:8:8 outputs. For example, a CEA 4K@60, RGB

[PATCH 15/15] drm/i915/glk: set HDMI 2.0 identifier

This patch sets the is_hdmi2_src identifier in drm connector for GLK platform. GLK contains a native HDMI 2.0 controller. This identifier will help the EDID handling functions to save lot of work which is specific to HDMI 2.0 sources. V3: Added this patch V4: Rebase V4: Rebase V5: Added r-b from

[PATCH 14/15] drm/i915: set colorspace for YCBCR420 outputs

When output colorspace is YCBCR420, we have to load the corresponding colorspace in AVI infoframe. This patch fills the colorspace of AVI infoframe as per the output mode. V2: Rebase V3: Rebase V4: Rebase V5: Added r-b from Ander V6: Checking RGB/YCBCR420 output only (Ville) Cc: Ville Syrjala

[PATCH] drm/radeon: Fix eDP for single-display iMac10,1 (v2)

The late 2009, 27 inch Apple iMac10,1 has an internal eDP display and an external Mini- Displayport output, driven by a DCE-3.2, RV730 Radeon Mobility HD-4670. The machine worked fine in a dual-display setup with eDP panel + externally connected HDMI or DVI-D digital display sink, connected via

[PATCH 10/15] drm/i915: add config function for YCBCR420 outputs

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 the mode is YCBCR420 and source can support this output then it marks the

[PATCH 07/15] drm/edid: parse ycbcr 420 deep color information

CEA-861-F spec adds ycbcr420 deep color support information in hf-vsdb block. This patch extends the existing hf-vsdb parsing function by adding parsing of ycbcr420 deep color support from the EDID and adding it into display information stored. V2: Rebase V3: Rebase V4: Moved definition of

[PATCH 08/15] drm: set output colorspace in AVI infoframe

A source must set output colorspace information in AVI infoframes, so that the sink can decode upcoming frames accordingly. This patch adds a function to add the output colorspace information in the AVI infoframes. V2: Rebase V3: Rebase V4: Rebase V5: Rebase V6: Made patch independent of HDMI

[PATCH 04/15] drm/edid: cleanup patch for CEA extended-tag macro

CEA-861-F introduces extended tag codes for EDID extension blocks, which indicates the actual type of the data block. The code for using exteded tag is 0x7, whereas in the existing code, the corresponding macro is named as "VIDEO_CAPABILITY_BLOCK" This patch renames the macro and usages from

[PATCH 05/15] 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

[PATCH 12/15] drm/i915: prepare pipe for YCBCR420 output

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 26 and 27) This patch: - Adds definition of these bits. - Programs PIPEMISC

[PATCH 13/15] drm/i915: prepare csc unit for YCBCR420 output

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. This function adds a csc handler, which uses recommended bspec values to

[PATCH 09/15] drm: add helper functions for YCBCR420 handling

This patch adds helper functions for YCBCR 420 handling. These functions do: - check if a given video mode is YCBCR 420 only mode. - check if a given video mode is YCBCR 420 also mode. V2: Added YCBCR functions as helpers in DRM layer, instead of keeping it in I915 layer. V3: Added handling

[PATCH 11/15] drm/i915: prepare scaler for YCBCR420 modeset

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 ycbcr420 output. - Adds a new scaler user "HDMI output" to plug-into existing

[PATCH 06/15] drm: add helper to validate YCBCR420 modes

YCBCR420 modes are supported only on HDMI 2.0 capable sources. This patch adds: - A drm helper to validate YCBCR420-only mode on a particular connector. This function will help pruning the YCBCR420-only modes from the connector's modelist. - A bool variable (ycbcr_420_allowed) in the drm

[PATCH v4 01/14] drm/atomic: export drm_atomic_replace_property_blob

While at it, add some words in the kernel-doc about the 'replaced' arg and remove a faulty kernel-doc comment on the return value. Also remove a redundant return statement. Signed-off-by: Peter Rosin --- drivers/gpu/drm/drm_atomic.c | 17 +

  1   2   >