4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k

L: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161201/98c4d7c3/attachment.html>

drm/radeon spamming alloc_contig_range: [xxx, yyy) PFNs busy busy

On Thu, Dec 01 2016, Michal Hocko wrote: > I am not familiar with this code so I cannot really argue but a quick > look at rmem_cma_setup doesn't suggest any speicific placing or > anything... early_cma parses ‘cma’ command line argument which can specify where exactly the default CMA area is

[PATCH 18/18] drm/i915/dsi: Skip delays for v3 VBTs in vid-mode

For v3 VBTs in vid-mode the delays are part of the VBT sequences, so we should not also delay ourselves otherwise we get double delays. Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/intel_dsi.c | 19 +++ 1 file changed, 15 insertions(+), 4 deletions(-) diff --git

[PATCH 17/18] drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode (untested)

According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON on enable for cmd-mode, just like we already call their counterparts on disable. Note: untested, my panel is a vid-mode panel. Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/intel_dsi.c | 2 ++ 1 file changed, 2

[PATCH 16/18] drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable

For v3 VBTs we should call MIPI_SEQ_TEAR_OFF before MIPI_SEQ_DISPLAY_OFF, for non v3 VBTs this is a nop. Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/intel_dsi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c

[PATCH 15/18] drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF order

According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN first. Since the v2 order has known issues, we use the v3 order everywhere, add a comment documenting this. Signed-off-by: Hans de Goede ---

[PATCH 14/18] drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight

Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as we call intel_panel_enable_backlight() / intel_panel_disable_backlight(). Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/intel_dsi.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git

[PATCH 13/18] drm/i915/dsi: Execute MIPI_SEQ_DEASSERT_RESET before calling device_ready()

Execute MIPI_SEQ_DEASSERT_RESET before putting the device in ready state (LP-11), this is the sequence in which things should be done according to the spec. Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/intel_dsi.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff

[PATCH 12/18] drm/i915/dsi: Group DPOunit clock gate workaround with PLL enable

Move the DPOunit clock gate workaround to directly after the PLL enable. The exact location of the workaround does not matter and there are 2 reasons to group it with the PLL enable: 1) This moves it out of the middle of the init sequence from the spec, making it easier to follow the init

[PATCH 11/18] drm/i915/dsi: Move MIPI_SEQ_POWER_ON/OFF calls together with pmic gpio calls

Now that we are no longer bound to the drm_panel_ callbacks, call MIPI_SEQ_POWER_ON/OFF at the proper place. Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/intel_dsi.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dsi.c

[PATCH 10/18] drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON

MIPI_SEQ_ASSERT_RESET before POWER_ON is not necessary for 2 reasons: 1) The reset should already be asserted before intel_dsi_pre_enable() gets called 2) Most (some?) VBTs will ensure reset was asserted in their MIPI_SEQ_DEASSERT_RESET themselves Signed-off-by: Hans de Goede ---

[PATCH 09/18] drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequences

The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are not fine grained enough to abstract all the different steps we need to take (and VBT sequences we need to exec) properly. So simply remove the panel _enable/disable and prepare/unprepare callbacks and instead export

[PATCH 08/18] drm/i915/dsi: Document the panel enable / disable sequences from the spec

Document the DSI panel enable / disable sequences from the spec, for easy comparison between the code and the spec. Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/intel_dsi.c | 64 1 file changed, 64 insertions(+) diff --git

[PATCH 07/18] drm/i915/dsi: Move intel_dsi_clear_device_ready()

Move the intel_dsi_clear_device_ready() function to higher up in intel_dsi.c this pairs it with intel_dsi_device_ready(); and pairs intel_dsi_*enable* with intel_dsi_*disable without intel_dsi_clear_device_ready() sitting in the middle of them. This commit purely moves code around, it does not

[PATCH 06/18] drm/i915/dsi: Move disable pll call outside of clear_device_ready()

On enable intel_dsi_enable() directly calls intel_enable_dsi_pll(), make intel_dsi_disable() also directly call intel_disable_dsi_pll(), rather then hiding the call in intel_dsi_clear_device_ready(), no functional changes. Signed-off-by: Hans de Goede --- drivers/gpu/drm/i915/intel_dsi.c | 4

[PATCH 05/18] drm/i915/dsi: Add intel_dsi_unprepare() helper

The enable path has an intel_dsi_prepare() helper which prepares various registers for the mode-set. Move the function undoing this to a new intel_dsi_unprepare() helper for better symmetry between the enable and disable paths. No functional changes. Signed-off-by: Hans de Goede ---

[PATCH 04/18] drm/i915/dsi: Merge intel_dsi_disable/enable into their respective callers

intel_dsi_disable/enable only have one caller, merge them into their respective callers. Change msleep(2) into usleep_range(2000, 5000) to make checkpatch happy, otherwise no funtional changes. The main advantage of this change is that it makes it easier to follow all the steps of the panel

[PATCH 03/18] drm/i915/dsi: Move calling of wait_for_dsi_fifo_empty to mipi_exec_send_packet

Instead of calling wait_for_dsi_fifo_empty on all dsi ports after calling a drm_panel_foo helper which calls VBT sequences, move it to the VBT mipi_exec_send_packet helper, which is the one VBT instruction which actually puts data in the fifo. This results in a nice cleanup making it clearer what

[PATCH 02/18] drm/i915/dsi: Fix chv_exec_gpio disabling the GPIOs it is setting

Set the CHV_GPIO_GPIOEN bit when updating GPIOs from chv_exec_gpio. Fixes: a0a6d4ffd2ad ("drm/i915/dsi: add support for gpio elements on CHV") Cc: stable at vger.kernel.org Cc: Jani Nikula Cc: Ville Syrjälä Signed-off-by: Hans de Goede Reviewed-by: Ville Syrjälä ---

[PATCH 01/18] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET

Looking at the ADF code from the Android kernel sources for a cherrytrail tablet I noticed that it is calling the MIPI_SEQ_ASSERT_RESET sequence from the panel prepare hook. Until commit b1cb1bd29189 ("drm/i915/dsi: update reset and power sequences in panel prepare/unprepare hooks") the mainline

[PATCH 00/18] drm/i915/dsi: Fix / cleanup dsi enable / disable sequences

Hi All, So while trying to fix my cherrytrail tablet's screen sometimes not initializing properly (*) I started working on this series to cleanup / (minor) refactor the dsi enable / disable code, with as goal to then change it to match the enable / disable sequences which Ville Syrjälä recently

[PATCH v2 7/7] ARM: bcm/dt: Enable the VEC IP on all RaspeberryPi boards

Enable the VEC IP on all RaspeberryPi boards. Signed-off-by: Boris Brezillon --- arch/arm/boot/dts/bcm2835-rpi.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi b/arch/arm/boot/dts/bcm2835-rpi.dtsi index e9b47b2bbc33..8893240da5f6 100644 ---

[PATCH v2 6/7] ARM: bcm/dt: Add VEC node in bcm283x.dtsi

Add the VEC (Video EnCoder) node definition in bcm283x.dtsi. Signed-off-by: Boris Brezillon --- arch/arm/boot/dts/bcm283x.dtsi | 8 1 file changed, 8 insertions(+) diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi index 46d46d894a44..44a9c0539437 100644 ---

[PATCH v2 5/7] drm/vc4: Document VEC DT binding

Document the DT binding for the VEC (Video EnCoder) IP. Signed-off-by: Boris Brezillon --- Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 14 ++ 1 file changed, 14 insertions(+) diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt

[PATCH v2 4/7] drm/vc4: Add support for the VEC (Video Encoder) IP

The VEC IP is a TV DAC, providing support for PAL and NTSC standards. Signed-off-by: Boris Brezillon --- drivers/gpu/drm/vc4/Makefile | 1 + drivers/gpu/drm/vc4/vc4_debugfs.c | 1 + drivers/gpu/drm/vc4/vc4_drv.c | 1 + drivers/gpu/drm/vc4/vc4_drv.h | 5 +

[PATCH v2 3/7] drm: Add TV connector states to drm_connector_state

Some generic TV connector properties are exposed in drm_mode_config, but they are currently handled independently in each DRM encoder driver. Extend the drm_connector_state to store TV related states, and modify the drm_atomic_connector_{set,get}_property() helpers to fill the connector state

[PATCH v2 2/7] drm: Turn DRM_MODE_SUBCONNECTOR_xx definitions into an enum

List of values like the DRM_MODE_SUBCONNECTOR_xx ones are better represented with enums. Turn the DRM_MODE_SUBCONNECTOR_xx macros into an enum. Signed-off-by: Boris Brezillon Suggested-by: Daniel Vetter --- include/uapi/drm/drm_mode.h | 18 ++ 1 file changed, 10 insertions(+),

[PATCH v2 1/7] drm/vc4: Fix ->clock_select setting for the VEC encoder

PV_CONTROL_CLK_SELECT_VEC is actually 2 and not 0. Fix the definition and rework the vc4_set_crtc_possible_masks() to cover the full range of the PV_CONTROL_CLK_SELECT field. Signed-off-by: Boris Brezillon --- drivers/gpu/drm/vc4/vc4_crtc.c | 38 +++---

[PATCH v2 0/7] drm/vc4: VEC (SDTV) output support

Here is the 2nd version of the VC4/VEC series. We still miss the two clock patches mentioned by Eric in the first version to make the encoder work no matter the setting applied by the bootloader. Regards, Boris Boris Brezillon (7): drm/vc4: Fix ->clock_select setting for the VEC encoder

[Bug 189451] New: UVD not responding with Mobility Radeon HD 5650

https://bugzilla.kernel.org/show_bug.cgi?id=189451 Bug ID: 189451 Summary: UVD not responding with Mobility Radeon HD 5650 Product: Drivers Version: 2.5 Kernel Version: 4.8.8 Hardware: All OS: Linux Tree:

linux-next: problems fetching the drm-intel, etc trees

Hi Stephen, On 1 December 2016 at 20:45, Stephen Rothwell wrote: > On Thu, 01 Dec 2016 11:02:26 + Daniel Stone > wrote: >> Sorry about this, it is quite bad. I think having mirrors for the key DRM >> trees on GitHub is a good idea though, and I can get to setting that up. >> Stephen, you

[Bug 98874] Desktop suddenly freezes, login via ssh possible, no error messages, unable to power off

nee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161201/7d3077aa/attachment.html>

[PATCH V3 3/3] drm: Add new driver for MXSFB controller

On 11/29/2016 09:15 PM, Daniel Vetter wrote: > On Tue, Nov 29, 2016 at 06:27:30PM +0100, Marek Vasut wrote: >> On 11/14/2016 12:47 PM, Daniel Vetter wrote: >>> On Mon, Nov 14, 2016 at 11:10:36AM +0100, Marek Vasut wrote: Add new driver for the MXSFB controller found in i.MX23/28/6SX .

[PULL] MXSFB driver

Hi, as asked by Daniel, I collected the MXSFB DT Acks and the driver and wrapped it into PR (below). -- The following changes since commit 09bfc750ec237029d69ebb749602b6f1304d028a: Add linux-next specific files for 20161125 (2016-11-25 14:11:29 +1100) are available in the git repository at:

[PATCH v2 0/7] Tests for sync infrastructure

On 10/19/2016 06:49 AM, Emilio López wrote: > Hello everyone, > > This is a series of tests to exercise the sync kernel infrastructure. It is > meant to be a test suite for the work Gustavo has been doing to destage it. > > These tests were originally part of a battery of tests shipping with >

[PATCH RFC 3/3] drm/tilcdc: Adapt to bridge object refcounting

Signed-off-by: Jyri Sarha --- drivers/gpu/drm/tilcdc/tilcdc_external.c | 15 +++ 1 file changed, 11 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/tilcdc/tilcdc_external.c b/drivers/gpu/drm/tilcdc/tilcdc_external.c index 80184f0..31c6092 100644 ---

[PATCH RFC 2/3] drm/bridge: ti-tfp410: Adapt to bridge object and module refcounting

Signed-off-by: Jyri Sarha --- drivers/gpu/drm/bridge/ti-tfp410.c | 16 ++-- 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-tfp410.c b/drivers/gpu/drm/bridge/ti-tfp410.c index b054ea3..f0c81dd 100644 --- a/drivers/gpu/drm/bridge/ti-tfp410.c

[PATCH RFC 1/3] drm/drm_bridge: adjust bridge module's refcount

Store the module that provides the bridge and adjust its reference count accordingly. The bridge module unload should not be allowed while the bridge is attached. To do this safely we need to add reference counting to drm_bridge objects. This has impact to both bridge drivers and the drivers using

[PATCH RFC 0/3] drm/bridge: adjust bridge module's refcount and more

Note! This series is not yet ready and should not be used as is, it is just an RFC. The function documentation is missing and so are the modifications to all affected drivers. I have added the modification patches for tilcdc and ti-tfp410 to serve as an example and I have put them into separate

[PATCH] gpu: vmwgfx: Use dma_pool_zalloc

Applied. Thanks. Reviewed-by: Sinclair Yeh On Fri, Dec 02, 2016 at 01:25:45AM +0530, Souptick Joarder wrote: > We should use dma_pool_zalloc instead of dma_pool_alloc/memset > > Signed-off-by: Souptick joarder > --- > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 10 -- > 1 file changed,

[PATCH v2 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

Just to let you know, I've not been ignoring all the ww_mutex stuff, I've been ill this week. I'm slowly returning to feeling human again, but am still fairly wrecked.

drm/radeon spamming alloc_contig_range: [xxx, yyy) PFNs busy busy

On Thu 01-12-16 17:03:52, Michal Nazarewicz wrote: > On Thu, Dec 01 2016, Michal Hocko wrote: > > Let's also CC Marek > > > > On Thu 01-12-16 08:43:40, Vlastimil Babka wrote: > >> On 12/01/2016 08:21 AM, Michal Hocko wrote: > >> > Forgot to CC Joonsoo. The email thread starts more or less here >

drm/radeon spamming alloc_contig_range: [xxx, yyy) PFNs busy busy

On Thu, Dec 01 2016, Michal Hocko wrote: > Let's also CC Marek > > On Thu 01-12-16 08:43:40, Vlastimil Babka wrote: >> On 12/01/2016 08:21 AM, Michal Hocko wrote: >> > Forgot to CC Joonsoo. The email thread starts more or less here >> > http://lkml.kernel.org/r/20161130092239.GD18437 at

[PATCH] drm/i915/dsi: Do not clear DPOUNIT_CLOCK_GATE_DISABLE from vlv_init_display_clock_gating

On my Cherrytrail CUBE iwork8 Air tablet PIPE-A would get stuck on loading i915 at boot 1 out of every 3 boots, resulting in a non functional LCD. Once the i915 driver has successfully loaded, the panel can be disabled / enabled without hitting this issue. The getting stuck is caused by

[PATCH v2] drm: Return -ENOTSUPP when called for KMS cap with a non-KMS driver

From: Michel Dänzer This is an attempt to make the previous fix a bit more robust going forward. v2: * Only allow DRM_CAP_TIMESTAMP_MONOTONIC with UMS drivers (Daniel Vetter, Alex Deucher) * Different logic to keep DRM_CAP_TIMESTAMP_MONOTONIC separate from the other

[PATCH 2/2] drm: Return -ENOTSUPP when called for KMS cap with a non-KMS driver

On 30/11/16 06:07 PM, Daniel Vetter wrote: > On Wed, Nov 30, 2016 at 05:30:02PM +0900, Michel Dänzer wrote: >> From: Michel Dänzer >> >> This is an attempt to make the previous fix a bit more robust going >> forward. >> >> Signed-off-by: Michel Dänzer >> --- >> drivers/gpu/drm/drm_ioctl.c |

[PATCH v2] drm: Return -ENOTSUPP when called for KMS cap with a non-KMS driver

On Thu, Dec 01, 2016 at 10:21:28AM -0500, Sean Paul wrote: > On Thu, Dec 1, 2016 at 2:37 AM, Michel Dänzer wrote: > > From: Michel Dänzer > > > > This is an attempt to make the previous fix a bit more robust going > > forward. > > It takes a bit of work to locate the "previous fix" now that

[PATCH v2 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

On Thu, Dec 01, 2016 at 02:18:04PM +, Chris Wilson wrote: > On Thu, Dec 01, 2016 at 03:06:44PM +0100, Nicolai Hähnle wrote: > > From: Nicolai Hähnle > > > > v2: use resv->lock instead of resv->lock.base (Christian König) > > > > Cc: Peter Zijlstra > > Cc: Ingo Molnar > > Cc: Maarten

[PATCH] drm/drm_bridge: adjust bridge module's refcount

On Thu, Dec 01, 2016 at 02:22:18PM +0100, Andrzej Hajda wrote: > On 01.12.2016 08:18, Daniel Vetter wrote: > > On Thu, Dec 01, 2016 at 08:07:29AM +0100, Andrzej Hajda wrote: > >> On 30.11.2016 14:09, Daniel Vetter wrote: > >>> On Wed, Nov 30, 2016 at 01:03:20PM +0200, Laurent Pinchart wrote: >

[PATCH]i915: use WARN_ON_ONCE in intel_dp_aux_transfer

On 12/01/16 at 04:00pm, Dave Young wrote: > On 11/30/16 at 03:25pm, Ville Syrjälä wrote: > > On Thu, Nov 24, 2016 at 05:03:20PM +0800, Dave Young wrote: > > > On 11/24/16 at 10:53am, Jani Nikula wrote: > > > > On Thu, 24 Nov 2016, Dave Young wrote: > > > > > I see a lot of below warning: > > >

[PATCH 1/2] drm/i915/dsi: Fix swapping of MIPI_SEQ_DEASSERT_RESET / MIPI_SEQ_ASSERT_RESET

Hi, On 29-11-16 14:06, Hans de Goede wrote: > p.s. > > I'm also trying to come up with some patches which properly > integrate pwm-lpss with the i915 driver instead of it > throwing a "Failed to own the pwm chip" error. But as soon > as I hook up things so that pwm_get() returns the pwm-lpss >

[PATCH]i915: use WARN_ON_ONCE in intel_dp_aux_transfer

On 11/30/16 at 03:25pm, Ville Syrjälä wrote: > On Thu, Nov 24, 2016 at 05:03:20PM +0800, Dave Young wrote: > > On 11/24/16 at 10:53am, Jani Nikula wrote: > > > On Thu, 24 Nov 2016, Dave Young wrote: > > > > I see a lot of below warning: > > > > > > No, we must not hide this under the carpet.

[PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

On Thu, Dec 01, 2016 at 03:06:48PM +0100, Nicolai Hähnle wrote: > @@ -677,15 +722,25 @@ __mutex_lock_common(struct mutex *lock, long state, > unsigned int subclass, > debug_mutex_lock_common(lock, ); > debug_mutex_add_waiter(lock, , task); > > - /* add waiting tasks to the end

[i.MX6 DRM IPUv3] Regression 4.9-rc5: greenish screen with YUV420 video

Hi Krzysztof, Am Donnerstag, den 17.11.2016, 10:43 +0100 schrieb Krzysztof Hałasa: > Hi, > > The following GStreamer pipeline causes screen to become green with > v4.9-rc4+: > > gst-launch-1.0 udpsrc uri=udp://239.1.2.2:5100 reuse=true >

[PATCH] drm: allow changing DPMS mode for non-CRTC displays

For non-CRTC displays, the drm_atomic_helper_connector_dpms will always set the connector back the old DPMS state before returning. This makes it impossible to change DPMS state. fixes: 0853695c3ba46f97dfc0b5885f7b7e640ca212dd Signed-off-by: Marta Lofstedt ---

[PATCH libdrm v2 5/5] xf86drm: implement an OpenBSD specific drmGetDevice2

DRI devices on OpenBSD are not in their own directory. They reside in /dev with a large number of statically generated /dev nodes. Avoid stat'ing all of /dev on OpenBSD by implementing this custom path. v2: - use drmGetMinorType to get node type - adapt to drmProcessPciDevice changes -

[PATCH libdrm v2 4/5] xf86drm: implement drmParsePciBusInfo for OpenBSD

Implement drmParsePciBusInfo for OpenBSD by using the new DRM_IOCTL_GET_PCIINFO ioctl. v2: use drmGetMinorType to get node type instead of always using DRM_NODE_PRIMARY. Signed-off-by: Jonathan Gray --- xf86drm.c | 24 1 file changed, 24 insertions(+) diff --git

[PATCH libdrm v2 3/5] xf86drm: implement drmParsePciDeviceInfo for OpenBSD

Implement drmParsePciDeviceInfo for OpenBSD by using the new DRM_IOCTL_GET_PCIINFO ioctl. v2: adapt to drmParsePciDeviceInfo changes and use drmOpenMinor Signed-off-by: Jonathan Gray --- xf86drm.c | 41 + 1 file changed, 41 insertions(+) diff --git

[PATCH libdrm v2 2/5] xf86drm: implement drmParseSubsystemType for OpenBSD

Implement drmParseSubsystemType for OpenBSD by always returning DRM_BUS_PCI. No non-pci drm drivers are in the kernel and this is unlikely to change anytime soon as the existing ones aren't permissively licensed. Signed-off-by: Jonathan Gray --- xf86drm.c | 2 ++ 1 file changed, 2

[PATCH libdrm v2 1/5] xf86drm: implement drmGetMinorNameForFD for non-sysfs

Implement drmGetMinorNameForFD for systems without sysfs by adapting drm_get_device_name_for_fd() from the Mesa loader. v2: use type parameter to select dev name instead of always using DRM_DEV_NAME Signed-off-by: Jonathan Gray --- xf86drm.c | 35 ++- 1 file

drm/radeon spamming alloc_contig_range: [xxx, yyy) PFNs busy busy

Let's also CC Marek On Thu 01-12-16 08:43:40, Vlastimil Babka wrote: > On 12/01/2016 08:21 AM, Michal Hocko wrote: > > Forgot to CC Joonsoo. The email thread starts more or less here > > http://lkml.kernel.org/r/20161130092239.GD18437 at dhcp22.suse.cz > > > > On Thu 01-12-16 08:15:07, Michal

[PATCH] drm/vmwgfx: Switch to mode_cmd2

One defect below otherwise: Reviewed-by: Sinclair Yeh On Wed, Nov 30, 2016 at 06:00:04PM +0100, Daniel Vetter wrote: > Surprisingly few changes needed to make it happen. Compile-tested > only. The idea is that this replaces the 2 patches from Ville's big > fb->format patch series as a prep

[PATCH v2 11/11] [rfc] locking/ww_mutex: Always spin optimistically for the first waiter

From: Nicolai Hähnle Check the current owner's context once against our stamp. If our stamp is lower, we continue to spin optimistically instead of backing off. This is correct with respect to deadlock detection because while the (owner, ww_ctx) pair may re-appear if

[PATCH v2 10/11] Documentation/locking/ww_mutex: Update the design document

From: Nicolai Hähnle Document the invariants we maintain for the wait list of ww_mutexes. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-devel at lists.freedesktop.org Signed-off-by: Nicolai Hähnle ---

[PATCH v2 09/11] locking/mutex: Initialize mutex_waiter::ww_ctx with poison when debugging

From: Nicolai Hähnle Help catch cases where mutex_lock is used directly on w/w mutexes, which otherwise result in the w/w tasks reading uninitialized data. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-devel at

[PATCH v2 08/11] locking/ww_mutex: Yield to other waiters from optimistic spin

From: Nicolai Hähnle Lock stealing is less beneficial for w/w mutexes since we may just end up backing off if we stole from a thread with an earlier acquire stamp that already holds another w/w mutex that we also need. So don't spin optimistically unless we are sure

[PATCH v2 07/11] locking/ww_mutex: Wake at most one waiter for back off when acquiring the lock

From: Nicolai Hähnle The wait list is sorted by stamp order, and the only waiting task that may have to back off is the first waiter with a context. The regular slow path does not have to wake any other tasks at all, since all other waiters that would have to back off

[PATCH v2 06/11] locking/ww_mutex: Notify waiters that have to back off while adding tasks to wait list

From: Nicolai Hähnle While adding our task as a waiter, detect if another task should back off because of us. With this patch, we establish the invariant that the wait list contains at most one (sleeping) waiter with ww_ctx->acquired > 0, and this waiter will be the

[PATCH v2 05/11] locking/ww_mutex: Add waiters in stamp order

From: Nicolai Hähnle Add regular waiters in stamp order. Keep adding waiters that have no context in FIFO order and take care not to starve them. While adding our task as a waiter, back off if we detect that there is a waiter with a lower stamp in front of us. Make

[PATCH v2 04/11] locking/ww_mutex: Set use_ww_ctx even when locking without a context

From: Nicolai Hähnle We will add a new field to struct mutex_waiter. This field must be initialized for all waiters if any waiter uses the ww_use_ctx path. So there is a trade-off: Keep ww_mutex locking without a context on the faster non-use_ww_ctx path, at the cost

[PATCH v2 03/11] locking/ww_mutex: Extract stamp comparison to __ww_mutex_stamp_after

From: Nicolai Hähnle The function will be re-used in subsequent patches. Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-devel at lists.freedesktop.org Signed-off-by: Nicolai Hähnle --- kernel/locking/mutex.c

[PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

From: Nicolai Hähnle In the following scenario, thread #1 should back off its attempt to lock ww1 and unlock ww2 (assuming the acquire context stamps are ordered accordingly). Thread #0 Thread #1 - -

[PATCH v2 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

From: Nicolai Hähnle v2: use resv->lock instead of resv->lock.base (Christian König) Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Maarten Lankhorst Cc: Daniel Vetter Cc: Chris Wilson Cc: dri-devel at lists.freedesktop.org Signed-off-by: Nicolai Hähnle ---

[PATCH] drm/omap: fix primary-plane's possible_crtcs

as I understand > always > up to num_crtcs. Can't we just use that value to compute possible_crtcs as (1 > << num_crtcs ) - 1 ? Yes, I think you're correct. It's not exactly obvious from the code =). I'll change the patch to use the calculated num-crtcs. 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/20161201/8a3f93b0/attachment.sig>

[PATCH v2 03/11] locking/ww_mutex: Extract stamp comparison to __ww_mutex_stamp_after

On Thu, Dec 01, 2016 at 03:06:46PM +0100, Nicolai Hähnle wrote: > From: Nicolai Hähnle > > The function will be re-used in subsequent patches. > > Cc: Peter Zijlstra > Cc: Ingo Molnar > Cc: Maarten Lankhorst > Cc: Daniel Vetter > Cc: Chris Wilson > Cc: dri-devel at lists.freedesktop.org

[PATCH v2 02/11] locking/ww_mutex: Re-check ww->ctx in the inner optimistic spin loop

On Thu, Dec 01, 2016 at 03:06:45PM +0100, Nicolai Hähnle wrote: > From: Nicolai Hähnle > > In the following scenario, thread #1 should back off its attempt to lock > ww1 and unlock ww2 (assuming the acquire context stamps are ordered > accordingly). > > Thread #0 Thread #1 >

[PATCH] drm/drm_bridge: adjust bridge module's refcount

On 01.12.2016 08:18, Daniel Vetter wrote: > On Thu, Dec 01, 2016 at 08:07:29AM +0100, Andrzej Hajda wrote: >> On 30.11.2016 14:09, Daniel Vetter wrote: >>> On Wed, Nov 30, 2016 at 01:03:20PM +0200, Laurent Pinchart wrote: On Wednesday 30 Nov 2016 11:55:20 Daniel Vetter wrote: > Why

[PATCH v2 01/11] drm/vgem: Use ww_mutex_(un)lock even with a NULL context

On Thu, Dec 01, 2016 at 03:06:44PM +0100, Nicolai Hähnle wrote: > From: Nicolai Hähnle > > v2: use resv->lock instead of resv->lock.base (Christian König) > > Cc: Peter Zijlstra > Cc: Ingo Molnar > Cc: Maarten Lankhorst > Cc: Daniel Vetter > Cc: Chris Wilson > Cc: dri-devel at

[PATCH] drm: allow changing DPMS mode for non-CRTC displays

On Thu, Dec 01, 2016 at 03:30:01PM +0200, Marta Lofstedt wrote: > For non-CRTC displays, A connector not attached to a CRTC works. It is the active connectors that were broken. > the drm_atomic_helper_connector_dpms > will always set the connector back the old DPMS state > before returning. This

[PATCH 1/3] drm: Add a new connector atomic property for link status

On Thu, Dec 1, 2016 at 1:58 PM, Manasi Navare wrote: > Sean, could you please review this patch, I have tried to address > all the comments from you. > Comments look good to me. Reviewed-by: Sean Paul Sean > Regards > Manasi > > On Tue, Nov 29, 2016 at 11:30:31PM -0800, Manasi Navare wrote:

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

On Thursday 01 Dec 2016 12:30:09 Jean-Francois Moine wrote: > On Thu, 01 Dec 2016 12:41:20 +0200 Laurent Pinchart wrote: > >>> If a DVI connector instead of a HDMI connector is soldered, how > >>> should such a device tree be written? > >> > >> Use a dvi-connector instead :) > > > > The HDMI

[PATCH libdrm 4/5] xf86drm: introduce drmGetDevice[s]2

On 1 December 2016 at 03:56, Michel Dänzer wrote: > On 01/12/16 12:09 PM, Michel Dänzer wrote: >> On 01/12/16 05:35 AM, Emil Velikov wrote: >>> From: Emil Velikov >>> >>> Relative to the original version, here one can provide a flags bitmask. >>> Currently only DRM_DEVICE_IGNORE_PCI_REVISION

[PATCH] drm: Make the connector .detect() callback optional

On Tue, Nov 29, 2016 at 4:09 PM, Laurent Pinchart wrote: > Hi Sean, > > On Tuesday 29 Nov 2016 16:07:02 Sean Paul wrote: >> On Tue, Nov 29, 2016 at 3:56 PM, Laurent Pinchart wrote: >> > Many drivers (21 to be exact) create connectors that are always >> > connected (for instance to an LVDS or DSI

[PATCH libdrm 4/5] xf86drm: introduce drmGetDevice[s]2

On 01/12/16 12:09 PM, Michel Dänzer wrote: > On 01/12/16 05:35 AM, Emil Velikov wrote: >> From: Emil Velikov >> >> Relative to the original version, here one can provide a flags bitmask. >> Currently only DRM_DEVICE_IGNORE_PCI_REVISION is supported. >> >> Implementation detail: >> If it's set,

[PATCH v2 7/7] ARM: bcm/dt: Enable the VEC IP on all RaspeberryPi boards

pgp-signature Size: 832 bytes Desc: not available URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161201/373b2a31/attachment-0001.sig>

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

On Thursday 01 Dec 2016 09:55:20 Maxime Ripard wrote: > On Thu, Dec 01, 2016 at 01:33:30AM +0800, Icenowy Zheng wrote: > >>> hdmi-out { > >>> compatible = "hdmi-connector"; > >>> type = "a"; > >>> /* I2C bus and GPIO references are made

[PATCH] drm/bridge: tc358767: don't warn if display side ASSR enable fails

Hi. I'm fine with that change. Acked-by:Andrey Gusakov On Thu, Dec 1, 2016 at 10:58 AM, Philipp Zabel wrote: > Am Donnerstag, den 01.12.2016, 09:56 +0530 schrieb Archit Taneja: >> >> On 11/30/2016 05:18 PM, Lucas Stach wrote: >> > ASSR is an optional feature, so it's a valid operating

[Bug 107381] radeon VCE init error (-110) -- AMD/Intel Mars Hybrid Graphics

https://bugzilla.kernel.org/show_bug.cgi?id=107381 --- Comment #15 from Stratos Zolotas --- I'm on 4.8.10 and still is not fixed. I have two AMD GPUS (both Oland) and the issue is appearing on both. So don't expect to see a fix on any released kernel. Haven't tested any 4.9 pre-release yet.

[linux-sunxi] Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI

On Thu, 01 Dec 2016 12:41:20 +0200 Laurent Pinchart wrote: > > > If a DVI connector instead of a HDMI connector is soldered, how > > > should such a device tree be written? > > > > Use a dvi-connector instead :) > > The HDMI encoder DT node doesn't (and certainly shouldn't) report what type >

[Bug 107381] radeon VCE init error (-110) -- AMD/Intel Mars Hybrid Graphics

https://bugzilla.kernel.org/show_bug.cgi?id=107381 Bhaskar changed: What|Removed |Added CC||bha100710 at gmail.com --- Comment #14 from

[Bug 98914] mesa-vdpau-drivers: breaks vdpau for mpeg2video

repository. I'll try to bisect in the next days. -- 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/20161201/d94f3567/attachment.html>

[Bug 188321] i915: black screen after disconnecting HDMI monitor

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

[PATCH libdrm 4/5] xf86drm: introduce drmGetDevice[s]2

On 01/12/16 05:35 AM, Emil Velikov wrote: > From: Emil Velikov > > Relative to the original version, here one can provide a flags bitmask. > Currently only DRM_DEVICE_IGNORE_PCI_REVISION is supported. > > Implementation detail: > If it's set, we will only parse the separate sysfs files and we

[PULL] drm-intel-fixes

Hi Dave, presumably final fixes for 4.9. BR, Jani. The following changes since commit e5517c2a5a49ed5e99047008629f1cd60246ea0e: Linux 4.9-rc7 (2016-11-27 13:08:04 -0800) are available in the git repository at: git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-fixes-2016-12-01

[RFC v3 1/3] fbmem: add default get_fb_unmapped_area function

On 01/12/16 04:46 AM, Benjamin Gaignard wrote: > 2016-11-30 20:39 GMT+01:00 Laurent Pinchart ideasonboard.com>: >> On Wednesday 30 Nov 2016 20:34:17 Benjamin Gaignard wrote: >>> If HAVE_ARCH_FB_UNMAPPED_AREA is set and get_fb_unmapped_area >>> function not defined in platform architecture let use

How should we group related devices in DT ? (was Re: [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support)

Hello, On Thursday 01 Dec 2016 10:13:13 Maxime Ripard wrote: [snip] > The earlier Allwinner SoCs (with the old display engine), we had some > SoCs with multiple instances of the display engine and TCON (the > display engine roughly implementing the planes, the TCON the > CRTC. Roughly.).

[pull] radeon and amdgpu drm-next-4.10

On Wed, Nov 23, 2016 at 3:40 PM, Alex Deucher wrote: > Hi Dave, > > More features for 4.10. Highlights: > - lots of code cleanup > - lots of bug fixes > - expose rpm based fan info via hwmon > - lots of clock and powergating fixes > - SI register header cleanup and conversion to common format

[PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support

Hi Maxime, On Thursday 01 Dec 2016 10:13:13 Maxime Ripard wrote: > On Wed, Nov 30, 2016 at 12:12:55PM +0200, Laurent Pinchart wrote: > >> More, it is not sure that the bridge/DW code would work with Allwinner's > >> SoCs. > > > > If it doesn't work and can't be made to work in a non-invasive way

[RFCv2 PATCH 1/5] video: add HDMI state notifier support

On 11/14/16 16:22, Hans Verkuil wrote: > From: Hans Verkuil > > Add support for HDMI hotplug and EDID notifiers, which is used to convey > information from HDMI drivers to their CEC and audio counterparts. I realized that the name 'HDMI notifier' isn't the best: the same mechanism can be used

linux-next: problems fetching the drm-intel, etc trees

drm-intel. Cheers, Daniel -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161201/4e2e493a/attachment.html>

  1   2   >