[PATCH 2/4] drm/i2c: tda998x: Remove obsolete drm_connector_register() call

On Thu, Oct 20, 2016 at 04:56:44PM +0530, Archit Taneja wrote: > 3) Rough conversion to bridge: So I thought I might give this a try, and see what's needed to complete the patch, but... I thought we'd got past the dark ages of email clients screwing up patches, but it seems not. This patch is

[PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

This function provides a way for the driver to redo a modeset on the current mode and retry the link training at a lower link rate/lane count/bpp. This will get called incase the link training fails during the current modeset. Cc: dri-devel at lists.freedesktop.org Cc: Jani Nikula Cc: Daniel

[PATCH 2/3] ARM: bus: da8xx-syscfg: new driver

On Friday 21 October 2016 02:55 PM, Tomi Valkeinen wrote: > On 20/10/16 22:39, Kevin Hilman wrote: > >> However, after our discussion on IRC, we'll respin this without the DT >> bindings at all. Next version will just use static configuration data >> in the drivers/bus driver based on SoC

[PATCH] drm/sun4i: Add a few formats

On Tue, Oct 18, 2016 at 4:46 PM, Maxime Ripard wrote: > The planes can do more than what was previously exposed. Add support for > them. > > Signed-off-by: Maxime Ripard > --- > drivers/gpu/drm/sun4i/sun4i_backend.c | 20 > drivers/gpu/drm/sun4i/sun4i_layer.c | 6 ++

[PATCH] drm/virtio: kconfig: Fixup white space.

On Sat, Oct 8, 2016 at 3:55 AM, Peter Griffin wrote: > Use tabs instead of spaces. > > Signed-off-by: Peter Griffin > Acked-by: Lee Jones Applied to drm-misc, thanks > --- > drivers/gpu/drm/virtio/Kconfig | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git

[PATCH 2/4] drm/i2c: tda998x: Remove obsolete drm_connector_register() call

On Thu, Oct 20, 2016 at 04:56:44PM +0530, Archit Taneja wrote: > > > On 10/20/2016 02:45 PM, Russell King - ARM Linux wrote: > >On Thu, Oct 20, 2016 at 02:38:25PM +0530, Archit Taneja wrote: > >> > >> > >>On 10/20/2016 01:50 PM, Laurent Pinchart wrote: > >>>Hi Russell, > >>> > >>>On Wednesday 19

[PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge

e work with drm bridge hdmi encoder > interface. The hdmi connector code isn't needed anymore as we expect > the adv7511 bridge driver to create/manage the connector. Tested-by: Ramiro Oliveira -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/cc4d153f/attachment-0001.html>

[PATCH 1/1] drm/mgag200: Added support for the new device G200eH3

From: Mathieu Larouche - Added the new device ID - Added new pll algorithm Signed-off-by: Mathieu Larouche --- drivers/gpu/drm/mgag200/mgag200_drv.c | 1 + drivers/gpu/drm/mgag200/mgag200_drv.h | 1 + drivers/gpu/drm/mgag200/mgag200_i2c.c | 1 +

[PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge

On 10/19/2016 01:16 PM, Eugeniy Paltsev wrote: > ARC PGU driver starts crashing on initialization after > 'commit e12c2f645557 ("drm/i2c: adv7511: Convert to drm_bridge")' > This happenes because in "arcpgu_drm_hdmi_init" function we get pointer > of "drm_i2c_encoder_driver" structure, which

[PATCH] dt-bindings: video: exynos7-decon: Remove obsolete samsung, power-domain property

The samsung,power-domain property is obsolete since commit 0da658704136 ("ARM: dts: convert to generic power domain bindings for exynos DT"). Replace it with generic one. Signed-off-by: Krzysztof Kozlowski --- Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt | 2 +- 1 file

[PATCH] drm: convert DT component matching to component_match_add_release()

On Thu, Oct 20, 2016 at 07:15:56PM -0400, Sean Paul wrote: > On Thu, Oct 20, 2016 at 5:50 PM, Russell King - ARM Linux > wrote: > > On Thu, Oct 20, 2016 at 04:39:04PM -0400, Sean Paul wrote: > >> On Wed, Oct 19, 2016 at 6:28 AM, Russell King > >> wrote: > >> >

[PATCH 2/5] drm: Define a work struct for scheduling a uevent for modeset retry

This work struct will be used to schedule a uevent on a separate thread. This will be scheduled after a link train failure during modeset to indicate a modeset retry request. It will get executed after the current modeset is complete and all locks are released. This was required to avoid deadlock.

[PATCH v6 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

On Thu, Oct 20, 2016 at 10:19:05PM +0100, Robert Bragg wrote: > +int i915_gem_context_pin_legacy_rcs_state(struct drm_i915_private *dev_priv, > + struct i915_gem_context *ctx, > + u64 flags) This is still no. > +static

[Bug 178421] [regression] Radeon Oops on shutdown

https://bugzilla.kernel.org/show_bug.cgi?id=178421 Kevin changed: What|Removed |Added CC||kvbevsauce at gmail.com --- Comment #2 from

[Bug 83531] radeon 6650m cannot boot without radeon.runpm=0

https://bugzilla.kernel.org/show_bug.cgi?id=83531 Kevin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Intel-gfx] linux-next: Tree for Oct 20 (gpu/drm/i915)

; ../include/drm/drmP.h:201:43: note: in definition of macro 'DRM_ERROR' > >> drm_printk(KERN_ERR, DRM_UT_NONE, fmt, ##__VA_ARGS__) > >>^ > >> ../drivers/gpu/drm/i915/gvt/gtt.c:1945:3: note: in expansion of macro > >>

[git pull] drm fixes for 4.9-rc2 (part 2)

Hi Linus, Second part of the fixes for rc2, main one being some vmwgfx fixes, also some armada, etnaviv and fsl-dcu fixes. There is a pretty large regression in -rc1 that affects radeon/amdgpu/nouveau and possibly other ttm using drivers with real VRAM on PAT systems, this was due to a change in

[PATCH 2/8] drm: bridge: vga-dac: Add adi,adv7123 compatible string

On 10/19/2016 07:55 PM, Laurent Pinchart wrote: > The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be > controlled through a power save pin, and requires a power supply. > However, on most boards where the device is used neither the power save > signal nor the power supply are

[PATCH 1/8] drm: bridge: Add LVDS encoder driver

On 10/19/2016 07:55 PM, Laurent Pinchart wrote: > The LVDS encoder driver is a DRM bridge driver that supports the > parallel to LVDS encoders that don't require any configuration. The > driver thus doesn't interact with the device, but creates an LVDS > connector for the panel and exposes its

[Bug 98146] DRI_PRIME=1 and fullscreen issues

today and this weekend to see if other problems are solved too, will write info asap. Big thanks for all help so far. -- You are receiving this mail because: You are the assignee for the bug. ------ next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/15cb48e4/attachment.html>

[PATCH 10/10] drm/imx: ipuv3-plane: use drm_plane_helper_check_state, clipped coordinates

On Thu, Oct 20, 2016 at 9:29 PM, Philipp Zabel wrote: > Am Donnerstag, den 20.10.2016, 16:51 +0800 schrieb Ying Liu: >> >> Does the clip thing potentially change the user's request by force? >> >> For example, the user request an unreasonable big resolution. >> > >> > The user is allowed to ask

[patch] drm/i915/gvt: cleanup a type issue in submit_context()

submit_context() should return negative error codes and zero on success but by mistake we made it a bool. I've changed it to int. Also I made it static because this isn't referenced in any other files. This doesn't affect runtime because the return is eventually propogated to elsp_mmio_write()

[PATCH 10/10] drm/imx: ipuv3-plane: use drm_plane_helper_check_state, clipped coordinates

Am Freitag, den 21.10.2016, 13:45 +0800 schrieb Ying Liu: > On Thu, Oct 20, 2016 at 9:29 PM, Philipp Zabel > wrote: > > Am Donnerstag, den 20.10.2016, 16:51 +0800 schrieb Ying Liu: > >> >> Does the clip thing potentially change the user's request by force? > >> >> For example, the user request

[PATCH] drm: Pass along the hotplug connector to the uevent

If we know which connector was plugged/unplugged or connected/disconnected, we can pass that information along to userspace inside the uevent to reduce the amount of work userspace has to perform after the event (i.e. instead of looking over all connectors, it can just reprobe the affected one).

[patch] drm/i915/gvt: cleanup a type issue in submit_context()

linux-next very soon. thanks -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available U

[Intel-gfx] [patch] drm/i915/gvt: cleanup a type issue in submit_context()

On Fri, Oct 21, 2016 at 11:06:01AM +0300, Dan Carpenter wrote: > submit_context() should return negative error codes and zero on success > but by mistake we made it a bool. I've changed it to int. Also I made > it static because this isn't referenced in any other files. > > This doesn't affect

[PATCH 10/10] drm/imx: ipuv3-plane: use drm_plane_helper_check_state, clipped coordinates

On Fri, Oct 21, 2016 at 4:18 PM, Philipp Zabel wrote: > Am Freitag, den 21.10.2016, 13:45 +0800 schrieb Ying Liu: >> On Thu, Oct 20, 2016 at 9:29 PM, Philipp Zabel >> wrote: >> > Am Donnerstag, den 20.10.2016, 16:51 +0800 schrieb Ying Liu: >> >> >> Does the clip thing potentially change the

[RFC] drm: add hint to userspace about whether a plane can scale

Hi Rob, On Thu, Oct 20, 2016 at 04:17:14PM -0400, Rob Clark wrote: >When you have a mix of planes that can scale and those that cannot >scale, userspace really wants to have some hint to know which planes >can definitely not scale so it knows to assign them to unscaled layers. >I don't think it

[PATCH v2] drm: Pass along the hotplug connector to the uevent

If we know which connector was plugged/unplugged or connected/disconnected, we can pass that information along to userspace inside the uevent to reduce the amount of work userspace has to perform after the event (i.e. instead of looking over all connectors, it can just reprobe the affected one).

[PATCH 2/3] ARM: bus: da8xx-syscfg: new driver

gp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/09458b88/attachment.sig>

[Intel-gfx] [PATCH v2] drm: Pass along the hotplug connector to the uevent

On Fri, 21 Oct 2016, Chris Wilson wrote: > If we know which connector was plugged/unplugged or > connected/disconnected, we can pass that information along to userspace > inside the uevent to reduce the amount of work userspace has to perform > after the event (i.e. instead of looking over all

[Bug 98352] [ctg bat] igt@kms_flip@basic-flip-vs-wf_vblank

/ -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/73df223e/attachment.html>

[PATCH v2] drm: Pass along the hotplug connector to the uevent

On Fri, Oct 21, 2016 at 10:14:21AM +0100, Chris Wilson wrote: > If we know which connector was plugged/unplugged or > connected/disconnected, we can pass that information along to userspace > inside the uevent to reduce the amount of work userspace has to perform > after the event (i.e. instead of

[PATCH v6 03/11] drm/i915: return EACCES for check_cmd() failures

On Thu, Oct 20, 2016 at 10:19:02PM +0100, Robert Bragg wrote: > @@ -1333,6 +1333,9 @@ int i915_cmd_parser_get_version(struct drm_i915_private > *dev_priv) >* 5. GPGPU dispatch compute indirect registers. >* 6. TIMESTAMP register and Haswell CS GPR registers >* 7. Allow

[PATCH 2/3] ARM: bus: da8xx-syscfg: new driver

for AM335x too. And perhaps for other SoCs too (AM4 comes to my mind). Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/4f710899/attachment.sig>

[PATCH v2] drm: Pass along the hotplug connector to the uevent

On Fri, Oct 21, 2016 at 12:46:53PM +0300, Ville Syrjälä wrote: > On Fri, Oct 21, 2016 at 10:14:21AM +0100, Chris Wilson wrote: > > If we know which connector was plugged/unplugged or > > connected/disconnected, we can pass that information along to userspace > > inside the uevent to reduce the

[PATCH 1/8] drm: bridge: Add LVDS encoder driver

Hi Archit, On Friday 21 Oct 2016 10:51:59 Archit Taneja wrote: > On 10/19/2016 07:55 PM, Laurent Pinchart wrote: > > The LVDS encoder driver is a DRM bridge driver that supports the > > parallel to LVDS encoders that don't require any configuration. The > > driver thus doesn't interact with the

[PATCH 2/8] drm: bridge: vga-dac: Add adi, adv7123 compatible string

Hi Archit, On Friday 21 Oct 2016 10:43:34 Archit Taneja wrote: > On 10/19/2016 07:55 PM, Laurent Pinchart wrote: > > The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be > > controlled through a power save pin, and requires a power supply. > > However, on most boards where the

[PATCH 2/8] drm: bridge: vga-dac: Add adi,adv7123 compatible string

On 10/21/2016 03:52 PM, Laurent Pinchart wrote: > Hi Archit, > > On Friday 21 Oct 2016 10:43:34 Archit Taneja wrote: >> On 10/19/2016 07:55 PM, Laurent Pinchart wrote: >>> The ADV7123 is a transparent VGA DAC. Unlike dumb VGA DACs it can be >>> controlled through a power save pin, and requires a

[PATCH v5 4/4] drm/fence: add out-fences support

Hi Gustavo, On Thu, Oct 20, 2016 at 06:30:17PM -0200, Gustavo Padovan wrote: >Hi Brian, > >2016-10-20 Brian Starkey : > >> Hi Gustavo, >> >> I notice your branch has the sync_file refcount change in, but this >> doesn't seem to take account for that. Will you be dropping that >> change to match

[Bug 93826] 2560x1440 @144Hz graphic glitches and bad refresh rate

e: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/d6517c9c/attachment.html>

[Bug 98361] [BDW /BXT/SKL/SNB] [Regression] drv_hangman subtests parser fail

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/99ca608e/attachment.html>

[PATCH]"drm: change DRM_MIPI_DSI module type from "bool" to "tristate".

On Thu, Oct 20, 2016 at 04:44:49PM +0300, Jani Nikula wrote: > On Thu, 20 Oct 2016, Andrzej Hajda wrote: > > Hi Jani, > > > > Forgive me late response. > > > > On 12.10.2016 16:28, Jani Nikula wrote: > >> On Wed, 12 Oct 2016, Emil Velikov wrote: > >>> On 11 October 2016 at 10:33, Jani Nikula >

[PATCH] dma-buf: Rename struct fence to dma_fence

On Thu, Oct 20, 2016 at 10:45:34PM +0530, Sumit Semwal wrote: > Hi Chris, > > Thanks for the patch! > > On 20 October 2016 at 17:38, Gustavo Padovan wrote: > > 2016-10-20 Chris Wilson : > > > >> I plan to usurp the short name of struct fence for a core kernel struct, > >> and so I need to

[Intel-gfx] i915 monitor hotplug on 4.1/4.4 PREEMPT

On Thu, Oct 20, 2016 at 05:09:52PM +0300, Nicolae Rosia wrote: > Hi, > > On Thu, Oct 20, 2016 at 3:57 PM, David Weinehall wrote: > >> > I get an udev event for unplugging, but there's no event generated for > >> > plugging the monitor back in. > >> > >> Does it work on non-RT? Does it work on

[PATCH] drm/fb-helper: Don't call dirty callback for untouched clips

On Thu, Oct 20, 2016 at 05:00:35PM +0200, Takashi Iwai wrote: > On Thu, 20 Oct 2016 16:56:04 +0200, > Ville Syrjälä wrote: > > > > On Thu, Oct 20, 2016 at 04:39:52PM +0200, Takashi Iwai wrote: > > > Since 4.7 kernel, we've seen the error messages like > > > > > > kernel: [TTM] Buffer eviction

[patch] drm/i915/gvt: cleanup a type issue in submit_context()

ks! Zhi, could you double check error path for elsp write? -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/8409966d/attachment.sig>

[RFC] drm: add hint to userspace about whether a plane can scale

On Fri, Oct 21, 2016 at 09:58:45AM +0100, Brian Starkey wrote: > Hi Rob, > > On Thu, Oct 20, 2016 at 04:17:14PM -0400, Rob Clark wrote: > > When you have a mix of planes that can scale and those that cannot > > scale, userspace really wants to have some hint to know which planes > > can

[Intel-gfx] [PATCH v2] drm: Pass along the hotplug connector to the uevent

On Fri, Oct 21, 2016 at 10:14:21AM +0100, Chris Wilson wrote: > If we know which connector was plugged/unplugged or > connected/disconnected, we can pass that information along to userspace > inside the uevent to reduce the amount of work userspace has to perform > after the event (i.e. instead of

[PATCH] drm/fb-helper: Don't call dirty callback for untouched clips

On Fri, 21 Oct 2016 14:30:32 +0200, Daniel Vetter wrote: > > On Thu, Oct 20, 2016 at 05:00:35PM +0200, Takashi Iwai wrote: > > On Thu, 20 Oct 2016 16:56:04 +0200, > > Ville Syrjälä wrote: > > > > > > On Thu, Oct 20, 2016 at 04:39:52PM +0200, Takashi Iwai wrote: > > > > Since 4.7 kernel, we've

[PATCH v5 1/4] drm/fence: add in-fences support

On Thu, Oct 20, 2016 at 12:50:02PM -0200, Gustavo Padovan wrote: > From: Gustavo Padovan > > There is now a new property called FENCE_FD attached to every plane > state that receives the sync_file fd from userspace via the atomic commit > IOCTL. > > The fd is then translated to a fence (that

[PATCH v2] drm/fb-helper: Don't call dirty callback for untouched clips

On Thu, Oct 20, 2016 at 05:05:30PM +0200, Takashi Iwai wrote: > Since 4.7 kernel, we've seen the error messages like > > kernel: [TTM] Buffer eviction failed > kernel: qxl :00:02.0: object_init failed for (4026540032, 0x0001) > kernel: [drm:qxl_alloc_bo_reserved [qxl]] *ERROR* failed

[PATCH v5 2/4] drm/fence: release fence reference when canceling event

On Thu, Oct 20, 2016 at 12:50:03PM -0200, Gustavo Padovan wrote: > From: Gustavo Padovan > > If the event gets canceled we also need to put away the fence > reference it holds. > > Signed-off-by: Gustavo Padovan Reviewed-by: Daniel Vetter I've broken my local dim scripts right now, so can't

[PATCH v5 3/4] drm/fence: add fence timeline to drm_crtc

On Thu, Oct 20, 2016 at 12:50:04PM -0200, Gustavo Padovan wrote: > From: Gustavo Padovan > > Create one timeline context for each CRTC to be able to handle out-fences > and signal them. It adds a few members to struct drm_crtc: fence_context, > where we store the context we get from

[PATCH v5 4/4] drm/fence: add out-fences support

On Thu, Oct 20, 2016 at 10:15:20PM +0300, Ville Syrjälä wrote: > On Thu, Oct 20, 2016 at 07:34:44PM +0300, Ville Syrjälä wrote: > > On Thu, Oct 20, 2016 at 01:55:38PM -0200, Gustavo Padovan wrote: > > > 2016-10-20 Ville Syrjälä : > > > > > > > On Thu, Oct 20, 2016 at 12:50:05PM -0200,

[PATCH] drm/fb-helper: Don't call dirty callback for untouched clips

On Fri, Oct 21, 2016 at 02:48:49PM +0200, Takashi Iwai wrote: > On Fri, 21 Oct 2016 14:30:32 +0200, > Daniel Vetter wrote: > > > > On Thu, Oct 20, 2016 at 05:00:35PM +0200, Takashi Iwai wrote: > > > On Thu, 20 Oct 2016 16:56:04 +0200, > > > Ville Syrjälä wrote: > > > > > > > > On Thu, Oct 20,

[Bug 98372] UBSAN in ../drivers/gpu/drm/drm_modes.c:325:49

this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/da7aa9ff/attachment.html>

[Bug 98372] UBSAN in ../drivers/gpu/drm/drm_modes.c:325:49

for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/5e9efde8/attachment.html>

[PATCH v5 4/4] drm/fence: add out-fences support

On Fri, Oct 21, 2016 at 11:55:52AM +0100, Brian Starkey wrote: > On Thu, Oct 20, 2016 at 06:30:17PM -0200, Gustavo Padovan wrote: > > 2016-10-20 Brian Starkey : > > > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h > > > > index 657a33a..b898604 100644 > > > > ---

[RFC] drm: add hint to userspace about whether a plane can scale

On Fri, Oct 21, 2016 at 4:58 AM, Brian Starkey wrote: > Hi Rob, > > On Thu, Oct 20, 2016 at 04:17:14PM -0400, Rob Clark wrote: >> >> When you have a mix of planes that can scale and those that cannot >> scale, userspace really wants to have some hint to know which planes >> can definitely not

[PATCH v5 0/4] drm: add explicit fencing

On Thu, Oct 20, 2016 at 12:50:01PM -0200, Gustavo Padovan wrote: > From: Gustavo Padovan > > Hi, > > Currently the Linux Kernel only have an implicit fencing mechanism, through > reservation objects, in which the fences are attached directly to buffers > operations and userspace is unaware of

[PATCH v5 4/4] drm/fence: add out-fences support

2016-10-21 Daniel Vetter : > On Thu, Oct 20, 2016 at 10:15:20PM +0300, Ville Syrjälä wrote: > > On Thu, Oct 20, 2016 at 07:34:44PM +0300, Ville Syrjälä wrote: > > > On Thu, Oct 20, 2016 at 01:55:38PM -0200, Gustavo Padovan wrote: > > > > 2016-10-20 Ville Syrjälä : > > > > > > > > > On Thu,

[Intel-gfx] [PATCH v2] drm: Pass along the hotplug connector to the uevent

On Fri, Oct 21, 2016 at 02:45:41PM +0200, Daniel Vetter wrote: > On Fri, Oct 21, 2016 at 10:14:21AM +0100, Chris Wilson wrote: > > If we know which connector was plugged/unplugged or > > connected/disconnected, we can pass that information along to userspace > > inside the uevent to reduce the

[Intel-gfx] i915 monitor hotplug on 4.1/4.4 PREEMPT

Hello, On Fri, Oct 21, 2016 at 3:27 PM, Daniel Vetter wrote: > So yeah, "upgrade" is very likely is. I see... i915.disable_power_well=0 seems to do the trick. Is it safe to use? The kernel gets tainted because of this. Regards, Nicolae

[RFC] drm: add hint to userspace about whether a plane can scale

On Fri, Oct 21, 2016 at 8:35 AM, Daniel Vetter wrote: > On Fri, Oct 21, 2016 at 09:58:45AM +0100, Brian Starkey wrote: >> Hi Rob, >> >> On Thu, Oct 20, 2016 at 04:17:14PM -0400, Rob Clark wrote: >> > When you have a mix of planes that can scale and those that cannot >> > scale, userspace really

[PATCH] drm/fb-helper: Don't call dirty callback for untouched clips

On Fri, Oct 21, 2016 at 02:30:32PM +0200, Daniel Vetter wrote: > On Thu, Oct 20, 2016 at 05:00:35PM +0200, Takashi Iwai wrote: > > On Thu, 20 Oct 2016 16:56:04 +0200, > > Ville Syrjälä wrote: > > > > > > On Thu, Oct 20, 2016 at 04:39:52PM +0200, Takashi Iwai wrote: > > > > Since 4.7 kernel,

[PATCH 1/6] video: of: Constify node argument to display timing functions

ent was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/edfcd1cb/attachment.sig>

[PATCH] drm: Add timestamp of last modification to GETCONNECTOR ioctl

After hotplug notification, userspace has to reprobe all connectors to detect any changes. This can be expensive (some outputs may require time consuming load detection, some outputs may simply be slow to respond) and not all outputs need to be checked everytime. The kernel is usually in a very

[PATCH] drm: Use u64 for intermediate dotclock calculations

We have reached the era where monitor bandwidths now exceed 31bits in frequency calculations, though as we stored them in kHz units we are safe from overflow in the modelines for some time. [ 48.723720] UBSAN: Undefined behaviour in ../drivers/gpu/drm/drm_modes.c:325:49 [ 48.726943] signed

[PATCH] drm: Use u64 for intermediate dotclock calculations

On Fri, Oct 21, 2016 at 10:15 AM, Chris Wilson wrote: > We have reached the era where monitor bandwidths now exceed 31bits in > frequency calculations, though as we stored them in kHz units we are > safe from overflow in the modelines for some time. > > [ 48.723720] UBSAN: Undefined behaviour

[patch] drm/i915/gvt: cleanup a type issue in submit_context()

On Fri, Oct 21, 2016 at 04:27:38PM +0800, Zhenyu Wang wrote: > On 2016.10.21 11:06:01 +0300, Dan Carpenter wrote: > > submit_context() should return negative error codes and zero on success > > but by mistake we made it a bool. I've changed it to int. Also I made > > it static because this isn't

[PATCH] dt-bindings: video: exynos7-decon: Remove obsolete samsung,power-domain property

On 10/21/2016 04:05 PM, Krzysztof Kozlowski wrote: > The samsung,power-domain property is obsolete since commit 0da658704136 > ("ARM: dts: convert to generic power domain bindings for exynos DT"). > Replace it with generic one. > > Signed-off-by: Krzysztof Kozlowski Reviewed-by: Sylwester

[PATCH 1/2] dma-buf/sync_file: hold reference to fence when creating sync_file

On Wed, Oct 19, 2016 at 1:48 PM, Gustavo Padovan wrote: > From: Gustavo Padovan > > fence referencing was out of balance. It was not taking any ref to the > fence at creating time, but it was putting a reference when freeing the > sync file. > > This patch fixes the balancing issue by getting a

[PATCH 2/2] drm/i915/gvt: fix compilation

Two functions in the newly added gvt render code are obviously broken, as they reference a variable without initialization and don't reference another variable at all: drivers/gpu/drm/i915/gvt/render.c: In function ‘intel_gvt_load_render_mmio’: drivers/gpu/drm/i915/gvt/render.c:148:13: error:

[PATCH] dt-bindings: video: exynos7-decon: Remove obsolete samsung,power-domain property

On 10/21/2016 11:36 AM, Sylwester Nawrocki wrote: > On 10/21/2016 04:05 PM, Krzysztof Kozlowski wrote: >> The samsung,power-domain property is obsolete since commit 0da658704136 >> ("ARM: dts: convert to generic power domain bindings for exynos DT"). >> Replace it with generic one. >> >>

[PATCH 1/2] drm/i915/gvt: add ACPI and 64BIT dependencies

The newly added gvt code produces lots of serious warnings and errors when either built on 32-bit x86, or built with ACPI disabled, e.g. drivers/gpu/drm/i915/gvt/gtt.c: In function ‘read_pte64’: drivers/gpu/drm/i915/gvt/gtt.c:277:2: error: left shift count >= width of type [-Werror]

[Bug 178281] wine-staging apps freezes the machine with RX460

https://bugzilla.kernel.org/show_bug.cgi?id=178281 --- Comment #9 from fin4478 at hotmail.com --- Now when I am playing TR 2013 with wine-1.9.21 (Staging) csmt enabled, gaming will will hang my machine when having fast actions. 10-20 minutes gaming is possible without rebooting. Using 64-bit

[PATCH v5 4/4] drm/fence: add out-fences support

Hi, Sorry, I hit another couple of bugs that originated from my hastebin patch - see below. On Thu, Oct 20, 2016 at 12:50:05PM -0200, Gustavo Padovan wrote: >From: Gustavo Padovan > >Support DRM out-fences by creating a sync_file with a fence for each CRTC >that sets the OUT_FENCE_PTR property.

[PATCH v6 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

ng well for quite a long time now. - Robert -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/2f58bebf/attachment.html>

[Intel-gfx] [PATCH v3 03/15] drm: Add support for optional per-plane rotation property

On Tue, Sep 27, 2016 at 01:22:48PM +0300, Ville Syrjälä wrote: > On Tue, Sep 27, 2016 at 12:54:46PM +0300, Joonas Lahtinen wrote: > > On ma, 2016-09-26 at 19:30 +0300, ville.syrjala at linux.intel.com wrote: > > > diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c > > > > >

[PATCH v2 08/15] drm/msm/mdp5: Set rotation property initial value to BIT(DRM_ROTATE_0) insted of 0

On Mon, Sep 26, 2016 at 07:30:53PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrjälä > > 0 isn't a valid rotation property value, so let's set the initial value > of the property to BIT(DRM_ROTATE_0) instead. > > In the same vein, we must always have at leat one angle as

[Intel-gfx] [PATCH v3 11/15] drm/i915: Use the per-plane rotation property

On Tue, Sep 27, 2016 at 12:58:49PM +0300, Joonas Lahtinen wrote: > On ma, 2016-09-26 at 19:30 +0300, ville.syrjala at linux.intel.com wrote: > > > From: Ville Syrjälä > > > > On certain platforms not all planes support the same set of > > rotations/reflections, so let's use the per-plane

[pull] radeon and amdgpu drm-fixes-4.9

Hi Dave, Misc bug fixes for radeon and amdgpu. The following changes since commit 26beaee9bb07be20cc641c1251152e280e80f54e: Merge branch 'drm-etnaviv-fixes' of git://git.pengutronix.de/lst/linux into drm-fixes (2016-10-21 13:27:55 +1000) are available in the git repository at:

[PATCH v2 08/15] drm/msm/mdp5: Set rotation property initial value to BIT(DRM_ROTATE_0) insted of 0

On Fri, Oct 21, 2016 at 06:26:54PM +0200, Daniel Vetter wrote: > On Mon, Sep 26, 2016 at 07:30:53PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrjälä > > > > 0 isn't a valid rotation property value, so let's set the initial value > > of the property to BIT(DRM_ROTATE_0)

[PATCH] drm: Add timestamp of last modification to GETCONNECTOR ioctl

On Fri, Oct 21, 2016 at 02:42:12PM +0100, Chris Wilson wrote: > After hotplug notification, userspace has to reprobe all connectors to > detect any changes. This can be expensive (some outputs may require time > consuming load detection, some outputs may simply be slow to respond) > and not all

[PATCH libdrm 1/2] Return an -ENODEV from drmGetDevice() when no device was found.

From: Rob Herring Fixes crashes in Mesa on platform device, which expected *device to have a device when 0 was returned. (code from a paste by Rob, commit message by anholt) Signed-off-by: Eric Anholt --- xf86drm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH] drm: tilcdc: implement palette loading for rev1

Revision 1 of the IP doesn't work if we don't load the palette (even if it's not used, which is the case for the RGB565 format). Add a function called from tilcdc_crtc_enable() which performs all required actions if we're dealing with a rev1 chip. Signed-off-by: Bartosz Golaszewski ---

[PATCH] drm: Add timestamp of last modification to GETCONNECTOR ioctl

On Fri, Oct 21, 2016 at 02:42:12PM +0100, Chris Wilson wrote: > After hotplug notification, userspace has to reprobe all connectors to > detect any changes. This can be expensive (some outputs may require time > consuming load detection, some outputs may simply be slow to respond) > and not all

[PATCH libdrm 1/2] Return an -ENODEV from drmGetDevice() when no device was found.

On Fri, Oct 21, 2016 at 1:12 PM, Eric Anholt wrote: > From: Rob Herring > > Fixes crashes in Mesa on platform device, which expected *device to > have a device when 0 was returned. > > (code from a paste by Rob, commit message by anholt) > > Signed-off-by: Eric Anholt Reviewed-by: Alex Deucher

[PATCH libdrm 2/2] Silence runtime complaints on platform devices

glxgears was spamming this 12 times at startup because of Mesa's probing of the DRM device code, which doesn't support platform devices. Signed-off-by: Eric Anholt --- xf86drm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/xf86drm.c b/xf86drm.c index 9b52889e4cef..52add5e441d7 100644

[PATCH libdrm 1/2] Return an -ENODEV from drmGetDevice() when no device was found.

On 21 October 2016 at 18:12, Eric Anholt wrote: > From: Rob Herring > > Fixes crashes in Mesa on platform device, which expected *device to > have a device when 0 was returned. > > (code from a paste by Rob, commit message by anholt) > > Signed-off-by: Eric Anholt Reviewed-by: Emil Velikov

[PATCH libdrm 2/2] Silence runtime complaints on platform devices

On Fri, Oct 21, 2016 at 1:12 PM, Eric Anholt wrote: > glxgears was spamming this 12 times at startup because of Mesa's > probing of the DRM device code, which doesn't support platform > devices. > > Signed-off-by: Eric Anholt Reviewed-by: Alex Deucher > --- > xf86drm.c | 2 -- > 1 file

[PATCH 2/4] drm/i2c: tda998x: Remove obsolete drm_connector_register() call

On Thu, 20 Oct 2016 16:56:44 +0530 Archit Taneja wrote: > > Please show _technically_ how this would work. I want to see code or > > pseudo-code illustrating how a "foreign" DRM encoder could be used with > > either dw-hdmi or tda998x, because right now I can't see any way that > > could work.

[Intel-gfx] i915 monitor hotplug on 4.1/4.4 PREEMPT

On Fri, Oct 21, 2016 at 04:21:53PM +0300, Nicolae Rosia wrote: > Hello, > > On Fri, Oct 21, 2016 at 3:27 PM, Daniel Vetter wrote: > > So yeah, "upgrade" is very likely is. > I see... > > i915.disable_power_well=0 seems to do the trick. > Is it safe to use? The kernel gets tainted because of

[PATCH] drm/fb-helper: Don't call dirty callback for untouched clips

On Fri, Oct 21, 2016 at 01:57:28PM +0100, Chris Wilson wrote: > On Fri, Oct 21, 2016 at 02:30:32PM +0200, Daniel Vetter wrote: > > On Thu, Oct 20, 2016 at 05:00:35PM +0200, Takashi Iwai wrote: > > > On Thu, 20 Oct 2016 16:56:04 +0200, > > > Ville Syrjälä wrote: > > > > > > > > On Thu, Oct 20,

[PATCH v6 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

up. > > > + dev_priv->perf.oa.oa_buffer.addr = i915_gem_object_pin_map(bo, > map); > > + if (IS_ERR(dev_priv->perf.oa.oa_buffer.addr)) { > > + ret = PTR_ERR(dev_priv->perf.oa.oa_buffer.addr); > > + goto err_unpin; > > + } > > -- > Chris Wilson, Intel Open Source Technology Centre > Thanks, - Robert -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161021/f35d133f/attachment.html>

[RFC] drm: add hint to userspace about whether a plane can scale

On Fri, Oct 21, 2016 at 09:26:22AM -0400, Rob Clark wrote: > On Fri, Oct 21, 2016 at 8:35 AM, Daniel Vetter wrote: > > On Fri, Oct 21, 2016 at 09:58:45AM +0100, Brian Starkey wrote: > >> Hi Rob, > >> > >> On Thu, Oct 20, 2016 at 04:17:14PM -0400, Rob Clark wrote: > >> > When you have a mix of

[PATCH] drm: Use u64 for intermediate dotclock calculations

On Fri, Oct 21, 2016 at 10:22:04AM -0400, Alex Deucher wrote: > On Fri, Oct 21, 2016 at 10:15 AM, Chris Wilson > wrote: > > We have reached the era where monitor bandwidths now exceed 31bits in > > frequency calculations, though as we stored them in kHz units we are > > safe from overflow in the

[PATCH] drm/i915: Enable i915 perf stream for Haswell OA unit

Gen graphics hardware can be set up to periodically write snapshots of performance counters into a circular buffer via its Observation Architecture and this patch exposes that capability to userspace via the i915 perf interface. v2: Make sure to initialize ->specific_ctx_id when opening,

[PATCH 2/4] drm/i2c: tda998x: Remove obsolete drm_connector_register() call

On Wed, Oct 19, 2016 at 12:19:30PM +0300, Laurent Pinchart wrote: (sorry, I lost your original mail) > >>> DRM bridges indeed don't create encoders. That task is left to the display > >>> driver. The reason is the same as above: bridges can be chained (including > >>> with an internal

  1   2   >