[PATCH] drm: idiot-proof vblank

On Wed, Aug 06, 2014 at 01:16:59PM -0400, Rob Clark wrote: > After spending slightly more time than I'd care to admit debugging the > various and presumably spectacular way things fail when you pass too low > a value to drm_vblank_init() (thanks console-lock for not letting me see > the carnage!),

i915 kernel warning

On Wed, Aug 06, 2014 at 10:03:46PM +0300, Mihai Don?u wrote: > Hi, > > This just happened to me: > > Aug 6 21:37:37 mdontu-l kernel: [ cut here ] > Aug 6 21:37:37 mdontu-l kernel: WARNING: CPU: 3 PID: 4823 at > drivers/gpu/drm/i915/intel_display.c:3313 >

[PATCH] drm: idiot-proof vblank

On Wed, Aug 06, 2014 at 03:06:40PM -0400, Rob Clark wrote: > On Wed, Aug 6, 2014 at 2:12 PM, Ville Syrj?l? > wrote: > > On Wed, Aug 06, 2014 at 01:16:59PM -0400, Rob Clark wrote: > >> After spending slightly more time than I'd care to admit debugging the > >> various and presumably spectacular

[PATCH 2/5] drm/radeon: add userptr flag to limit it to anonymous memory v2

On Wed, Aug 06, 2014 at 02:34:16PM -0400, Jerome Glisse wrote: > On Wed, Aug 06, 2014 at 07:17:25PM +0200, Christian K?nig wrote: > > Am 06.08.2014 um 18:08 schrieb Jerome Glisse: > > >On Wed, Aug 06, 2014 at 08:55:28AM +0200, Christian K?nig wrote: > > >>Am 06.08.2014 um 00:13 schrieb Jerome

i915 kernel warning

Hi, This just happened to me: Aug 6 21:37:37 mdontu-l kernel: [ cut here ] Aug 6 21:37:37 mdontu-l kernel: WARNING: CPU: 3 PID: 4823 at drivers/gpu/drm/i915/intel_display.c:3313 intel_crtc_wait_for_pending_flips+0x16c/0x180() Aug 6 21:37:37 mdontu-l kernel: Modules

[PATCH] drm: Don't grab an fb reference for the idr

On Wed, Aug 06, 2014 at 02:59:29PM -0400, Rob Clark wrote: > On Wed, Aug 6, 2014 at 10:07 AM, Daniel Vetter wrote: > > On Wed, Aug 06, 2014 at 09:12:42AM -0400, Rob Clark wrote: > >> On Wed, Aug 6, 2014 at 8:37 AM, Daniel Vetter wrote: > >> > On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark

[Bug 78453] [HAWAII] Get acceleration working

nts/20140806/309ca314/attachment.html>

[PATCH] drm: idiot-proof vblank

On Wed, Aug 06, 2014 at 01:16:59PM -0400, Rob Clark wrote: > After spending slightly more time than I'd care to admit debugging the > various and presumably spectacular way things fail when you pass too low > a value to drm_vblank_init() (thanks console-lock for not letting me see > the carnage!),

[Bug 81644] Random crashes on RadeonSI with Chromium.

ause: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/eeaf534b/attachment.html>

[Bug 81644] Random crashes on RadeonSI with Chromium.

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

[PATCH libdrm] drm: Implement drmCheckModesettingSupported() for DragonFly

On Sat, Jul 26, 2014 at 01:39:58PM +0200, Fran?ois Tigeot wrote: > For the sake of simplicity, KMS support can always be considered > present on DragonFly. > > If some particular version doesn't support KMS yet, appropriate > checks are already done in Dports's x11-drivers/ Makefiles and >

[PATCH 2/5] drm/radeon: add userptr flag to limit it to anonymous memory v2

Am 06.08.2014 um 18:08 schrieb Jerome Glisse: > On Wed, Aug 06, 2014 at 08:55:28AM +0200, Christian K?nig wrote: >> Am 06.08.2014 um 00:13 schrieb Jerome Glisse: >>> On Tue, Aug 05, 2014 at 07:45:21PM +0200, Christian K?nig wrote: Am 05.08.2014 um 19:39 schrieb Jerome Glisse: > On Tue,

[PULL] DRM Cleanups

On 6 August 2014 16:58, David Herrmann wrote: > Hi Dave > > A bunch of cleanups that are all reviewed by Daniel and Alex. Has survived the > compile/runtime test bots for some weeks now, so should all be fine. Nothing > critical, though. > > This series includes: > * hide ctxbitmap harder so

[PATCH 4/5] drm/radeon: add userptr flag to register MMU notifier v3

Am 06.08.2014 um 17:16 schrieb Jerome Glisse: > On Tue, Aug 05, 2014 at 06:05:31PM +0200, Christian K?nig wrote: >> From: Christian K?nig >> >> Whenever userspace mapping related to our userptr change >> we wait for it to become idle and unmap it from GTT. >> >> v2: rebased, fix mutex unlock in

[PATCH] drm: Renaming DP training vswing/pre-emph defines

From: Sonika Jindal Rename the defines to have levels instead of values for vswing and pre-emph levels as the values may differ in other scenarios like low vswing of eDP 1.4 where the values are different. v2: Keeping old and new defines (Danvet), adding description in

[PATCH 9/9] ARM: OMAP2+: omap2plus_defconfig: Enable BeagleBone Black HDMI audio support

Select CONFIG_SND_EDMA_SOC=m and CONFIG_SND_AM335X_SOC_NXPTDA_EVM=m for BBB HDMI audio. Signed-off-by: Jyri Sarha --- arch/arm/configs/omap2plus_defconfig |2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig index

[PATCH 8/9] ARM: OMAP2+: omap2plus_defconfig: TDA998X HDMI trough tilcdc, slave

Select CONFIG_DRM=m, CONFIG_DRM_I2C_NXP_TDA998X=m, and CONFIG_DRM_TILCDC=m, for Beaglebone-Black HDMI video support. Signed-off-by: Jyri Sarha --- arch/arm/configs/omap2plus_defconfig |3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/omap2plus_defconfig

[PATCH 7/9] ARM: dts: am335x-boneblack: Add HDMI audio support

Adds mcasp0_pins, clk_mcasp0_fixed, clk_mcasp0, mcasp0, hdmi_audio, and sound nodes. Signed-off-by: Jyri Sarha --- arch/arm/boot/dts/am335x-boneblack.dts | 54 1 file changed, 54 insertions(+) diff --git a/arch/arm/boot/dts/am335x-boneblack.dts

[PATCH 6/9] ARM: dts: am33xx: Add external clock provider

Add external clock provaider for am33xx devices. Signed-off-by: Jyri Sarha --- arch/arm/boot/dts/am33xx.dtsi | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi index 4a4e02d..5093c64 100644 ---

[PATCH 5/9] ASoC: davinci: HDMI audio build for AM33XX and TDA998x

Adds configuration option for HDMI audio support for AM33XX based boards with NXP TDA998x HDMI transmitter. The audio is connected to NXP TDA998x trough McASP running in i2s mode. Signed-off-by: Jyri Sarha --- sound/soc/davinci/Kconfig | 12 1 file changed, 12 insertions(+) diff

[PATCH 4/9] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus

Add machine driver support for BeagleBone-Black HDMI audio. BBB has NXP TDA998X HDMI transmitter connected to McASP port in I2S mode. The 44100 Hz sample-rate and it's multiples can not be accurately produced on BBB. The only supported sample format is SNDRV_PCM_FORMAT_S32_LE. The 8 least

[PATCH 3/9] drm/tilcdc: Add I2S HDMI audio config for tda998x

The configuration is needed for HDMI audio. The "swap" and "mirr" parameters have to be correctly set in the configuration in order to have proper colors in the HDMI picture. Signed-off-by: Jyri Sarha --- drivers/gpu/drm/tilcdc/tilcdc_slave.c | 24 +++- 1 file changed, 23

[PATCH 2/9] clk: add gpio controlled clock

The added clk-gpio is a basic clock that can be enabled and disabled trough a gpio output. The DT binding document for the clock is also added. For EPROBE_DEFER handling the registering of the clock has to be delayed until of_clk_get() call time. Signed-off-by: Jyri Sarha ---

[PATCH 1/9] ASoC: mcasp: Fix implicit BLCK divider setting

The implicit BLCK divider setting was broken by "ASoC: mcasp: don't override bclk divider if it was provided by the machine"-patch. After the BCLK divider is implicitly set for the first time the mcasp->bclk_div gets a non zero value and the implicit setting is "turned off". Signed-off-by: Jyri

[PATCH 0/9] Beaglebone-Black HDMI audio

The code has a functional dependency to: http://www.mail-archive.com/linux-omap at vger.kernel.org/msg108199.html Without the above patch the audio card does not probe. The code has been rebased on top of Linux 3.16 merged with git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git

[Intel-gfx] [PATCH 17/19] drm/i915: Clear .last vblank count before drm_vblank_off() when sanitizing crtc state

On Wed, Aug 06, 2014 at 03:30:17PM +0200, Daniel Vetter wrote: > On Wed, Aug 06, 2014 at 02:50:00PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrj?l? > > > > We call drm_vblank_off() during crtc sanitation to make sure the > > software and hardware states agree. However

[PATCH] drm/panel/simple: add optronics B101XTN01.0

On Wed, Aug 6, 2014 at 4:31 PM, Rob Clark wrote: > LVDS panel, make/model described as: > > AU Optronics Corporation - B101XTN01.0 (H/W:0A) > > See: > http://www.encore-electronic.com/media/B101XTN01.0.pdf > > Signed-off-by: Rob Clark > --- > drivers/gpu/drm/panel/panel-simple.c | 27

[Intel-gfx] [PATCH 09/19] drm: Fix race between drm_vblank_off() and drm_queue_vblank_event()

On Wed, Aug 06, 2014 at 03:23:01PM +0200, Daniel Vetter wrote: > On Wed, Aug 06, 2014 at 02:49:52PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrj?l? > > > > Currently it's possible that the following will happen: > > 1. drm_wait_vblank() calls drm_vblank_get() > > 2.

[PATCH] drm: idiot-proof vblank

On Wed, Aug 6, 2014 at 4:28 PM, Daniel Vetter wrote: > On Wed, Aug 06, 2014 at 03:06:40PM -0400, Rob Clark wrote: >> On Wed, Aug 6, 2014 at 2:12 PM, Ville Syrj?l? >> wrote: >> > On Wed, Aug 06, 2014 at 01:16:59PM -0400, Rob Clark wrote: >> >> After spending slightly more time than I'd care to

[PATCH] drm/panel/simple: add optronics B101XTN01.0

LVDS panel, make/model described as: AU Optronics Corporation - B101XTN01.0 (H/W:0A) See: http://www.encore-electronic.com/media/B101XTN01.0.pdf Signed-off-by: Rob Clark --- drivers/gpu/drm/panel/panel-simple.c | 27 +++ 1 file changed, 27 insertions(+) diff --git

[Intel-gfx] [PATCH 15/19] drm: Update vblank->last in drm_update_vblank_count()

On Wed, Aug 06, 2014 at 03:08:25PM +0200, Daniel Vetter wrote: > On Wed, Aug 06, 2014 at 02:49:58PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrj?l? > > > > We should update the last in drm_update_vblank_count() to avoid applying > > the diff more than once. This could

[Intel-gfx] [PATCH 15/19] drm: Update vblank->last in drm_update_vblank_count()

On Wed, Aug 06, 2014 at 04:30:29PM +0300, Ville Syrj?l? wrote: > On Wed, Aug 06, 2014 at 03:08:25PM +0200, Daniel Vetter wrote: > > On Wed, Aug 06, 2014 at 02:49:58PM +0300, ville.syrjala at linux.intel.com > > wrote: > > > From: Ville Syrj?l? > > > > > > We should update the last in

[PATCH igt] tests: Add kms_flip_event_leak test

From: Ville Syrj?l? kms_flip_event_leak will issue a page flip and close the file descriptor before the flip has finished. This may cause the kernel to leak the page flip event. The test itself won't actually fail but if the kernel notices the leak and WARNs piglit

[PATCH v2 1/2] drm/mipi-dsi: add (LPM) Low Power Mode transfer support

Thanks for comments. On 2014? 08? 05? 20:12, Thierry Reding wrote: > On Mon, Jul 28, 2014 at 06:09:58PM +0200, Andrzej Hajda wrote: >> On 07/28/2014 04:00 AM, Inki Dae wrote: >>> This patch adds below two flags for LPM transfer, and it attaches LPM flags >>> to a msg in accordance with master's

[Intel-gfx] [PATCH 2/2] drm/i915: Free pending page flip events at .preclose()

On Wed, Aug 06, 2014 at 02:02:51PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > If there are pending page flips when the fd gets closed those page > flips may have events associated to them. When the page flip eventually > completes it will queue the event to

[PATCH] drm: Don't grab an fb reference for the idr

On Wed, Aug 06, 2014 at 09:12:42AM -0400, Rob Clark wrote: > On Wed, Aug 6, 2014 at 8:37 AM, Daniel Vetter wrote: > > On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark wrote: > >> On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter > >> wrote: > >> > The current refcounting scheme is that the fb

[PATCH 3/3] drm: Use vblank_disable_and_save in drm_vblank_cleanup()

On Wed, Aug 06, 2014 at 01:51:41PM +0300, Ville Syrj?l? wrote: > On Wed, Aug 06, 2014 at 03:22:46AM +0200, Mario Kleiner wrote: > > Calling vblank_disable_fn() will cause that function to no-op > > if !dev->vblank_disable_allowed for some kms drivers, e.g., > > on nouveau-kms. This can cause the

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

7 + patch from attachment 104101. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/3f940f6f/attachment-0001.html>

[Bug 82162] Syslog flooded by [drm:radeon_gem_object_create] errors

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/063bc9d6/attachment.html>

[Intel-gfx] [PATCH 17/19] drm/i915: Clear .last vblank count before drm_vblank_off() when sanitizing crtc state

On Wed, Aug 06, 2014 at 02:50:00PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > We call drm_vblank_off() during crtc sanitation to make sure the > software and hardware states agree. However drm_vblank_off() will > try to update the vblank timestamp and sequence

[Bug 82162] Syslog flooded by [drm:radeon_gem_object_create] errors

ase, but we might want to figure out why it happened in the first place. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20

[Intel-gfx] [PATCH 09/19] drm: Fix race between drm_vblank_off() and drm_queue_vblank_event()

On Wed, Aug 06, 2014 at 02:49:52PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > Currently it's possible that the following will happen: > 1. drm_wait_vblank() calls drm_vblank_get() > 2. drm_vblank_off() gets called > 3. drm_wait_vblank() calls

[Bug 82162] Syslog flooded by [drm:radeon_gem_object_create] errors

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140806/44138098/attachment.html>

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

ou are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/a29aa51f/attachment.html>

[Bug 81680] [r600g] Firefox crashes with hardware acceleration turned on

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/4fbffa31/attachment.html>

[Bug 82162] Syslog flooded by [drm:radeon_gem_object_create] errors

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

[Intel-gfx] [PATCH 16/19] drm: Store the vblank timestamp when adjusting the counter during disable

On Wed, Aug 06, 2014 at 02:49:59PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > During vblank disable the code tries to guess based on the > timestamps whether we just missed one vblank or not. And if so > it increments the counter. However it forgets to store the

[Intel-gfx] [PATCH 14/19] drm: Don't update vblank timestamp when the counter didn't change

On Wed, Aug 06, 2014 at 02:56:14PM +0200, Daniel Vetter wrote: > On Wed, Aug 06, 2014 at 02:49:57PM +0300, ville.syrjala at linux.intel.com > wrote: > > From: Ville Syrj?l? > > > > If we already have a timestamp for the current vblank counter, don't > > update it with a new timestmap. Small

[Bug 82162] Syslog flooded by [drm:radeon_gem_object_create] errors

/dri-devel/attachments/20140806/bde0754e/attachment-0001.html>

[Intel-gfx] [PATCH 15/19] drm: Update vblank->last in drm_update_vblank_count()

On Wed, Aug 06, 2014 at 02:49:58PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > We should update the last in drm_update_vblank_count() to avoid applying > the diff more than once. This could occur eg. if drm_vblank_off() gets > called multiple times for the crtc. >

[PATCH] drm: idiot-proof vblank

On Wed, Aug 6, 2014 at 2:12 PM, Ville Syrj?l? wrote: > On Wed, Aug 06, 2014 at 01:16:59PM -0400, Rob Clark wrote: >> After spending slightly more time than I'd care to admit debugging the >> various and presumably spectacular way things fail when you pass too low >> a value to drm_vblank_init()

[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance

An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/5b571254/attachment.html>

[Bug 82253] New: JanusVR Browser rendering misses floors on radeonsi, works on intel

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/77f5502b/attachment.html>

[PATCH] drm: Don't grab an fb reference for the idr

On Wed, Aug 6, 2014 at 10:07 AM, Daniel Vetter wrote: > On Wed, Aug 06, 2014 at 09:12:42AM -0400, Rob Clark wrote: >> On Wed, Aug 6, 2014 at 8:37 AM, Daniel Vetter wrote: >> > On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark wrote: >> >> On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter >> >>

[Intel-gfx] [PATCH 14/19] drm: Don't update vblank timestamp when the counter didn't change

On Wed, Aug 06, 2014 at 02:49:57PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > If we already have a timestamp for the current vblank counter, don't > update it with a new timestmap. Small errors can creep in between two > timestamp queries for the same vblank count,

[PATCH 2/2] drm: Perform cmdline mode parsing during connector initialisation

From: Chris Wilson i915.ko has a custom fbdev initialisation routine that aims to preserve the current mode set by the BIOS, unless overruled by the user. The user's wishes are determined by what, if any, mode is specified on the command line (via the video= parameter).

[PATCH 1/2] video/fbdev: Always built-in video= cmdline parsing

In drm/i915 we want to get at the video= cmdline modes even when we don't have fbdev support enabled, so that users can always override the kernel's initial mode selection. But that gives us a direct depency upon the parsing code in the fbdev subsystem. Since it's so little code just extract

[Intel-gfx] [PATCH 2/2] drm/i915: Free pending page flip events at .preclose()

On Wed, Aug 06, 2014 at 02:02:51PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > If there are pending page flips when the fd gets closed those page > flips may have events associated to them. When the page flip eventually > completes it will queue the event to

[PATCH igt] tests/kms_flip: Assert that vblank timestamps aren't zeroed

From: Ville Syrj?l? The kernel might mistakenly send out a zeroed vblank timestamp when the vblank wait gets terminated early due to crtc disable. Add an assertion to catch that. Signed-off-by: Ville Syrj?l? --- tests/kms_flip.c | 3 +++ 1 file changed, 3

[PATCH 19/19] drm: Fix confusing debug message in drm_update_vblank_count()

From: Ville Syrj?l? Now that drm_update_vblank_count() can be called even when we're not about to enable the vblank interrupts we shouldn't print debug messages stating otherwise. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_irq.c | 2 +- 1 file changed,

[PATCH 18/19] drm/i915: Update scanline_offset only for active crtcs

From: Ville Syrj?l? update_scanline_offset() in intel_sanitize_crtc() was supposed to be called only for active crtcs. But due to some underrun patches it now gets updated for all crtcs on gmch platforms. Move the update_scanline_offset() to the very beginning of

[PATCH 17/19] drm/i915: Clear .last vblank count before drm_vblank_off() when sanitizing crtc state

From: Ville Syrj?l? We call drm_vblank_off() during crtc sanitation to make sure the software and hardware states agree. However drm_vblank_off() will try to update the vblank timestamp and sequence number which lands us in some trouble. As the pipe is disabled

[PATCH 16/19] drm: Store the vblank timestamp when adjusting the counter during disable

From: Ville Syrj?l? During vblank disable the code tries to guess based on the timestamps whether we just missed one vblank or not. And if so it increments the counter. However it forgets to store the new timestamp to the approriate slot in our timestamp ring

[PATCH 15/19] drm: Update vblank->last in drm_update_vblank_count()

From: Ville Syrj?l? We should update the last in drm_update_vblank_count() to avoid applying the diff more than once. This could occur eg. if drm_vblank_off() gets called multiple times for the crtc. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_irq.c | 2

[PATCH 14/19] drm: Don't update vblank timestamp when the counter didn't change

From: Ville Syrj?l? If we already have a timestamp for the current vblank counter, don't update it with a new timestmap. Small errors can creep in between two timestamp queries for the same vblank count, which could be confusing to userspace when it queries the

[PATCH v2 13/19] drm: Kick start vblank interrupts at drm_vblank_on()

From: Ville Syrj?l? If the user is interested in getting accurate vblank sequence numbers all the time they may disable the vblank disable timer entirely. In that case it seems appropriate to kick start the vblank interrupts already from drm_vblank_on(). v2: Adapt

[PATCH 12/19] drm/i915: Opt out of vblank disable timer on >gen2

From: Ville Syrj?l? Now that the vblank races are plugged, we can opt out of using the vblank disable timer and just let vblank interrupts get disabled immediately when the last reference is dropped. Gen2 is the exception since it has no hardware frame counter.

[PATCH v2 11/19] drm: Add dev->vblank_disable_immediate flag

From: Ville Syrj?l? Add a flag to drm_device which will cause the vblank code to bypass the disable timer and always disable the vblank interrupt immediately when the last reference is dropped. v2: Add some notes about the flag to the kernel doc Reviewed-by: Matt

[PATCH v2 10/19] drm: Disable vblank interrupt immediately when drm_vblank_offdelay<0

From: Ville Syrj?l? Make drm_vblank_put() disable the vblank interrupt immediately when the refcount drops to zero and drm_vblank_offdelay<0. v2: Preserve the current drm_vblank_offdelay==0 'never disable' behaviur Reviewed-by: Matt Roper Signed-off-by: Ville

[PATCH 09/19] drm: Fix race between drm_vblank_off() and drm_queue_vblank_event()

From: Ville Syrj?l? Currently it's possible that the following will happen: 1. drm_wait_vblank() calls drm_vblank_get() 2. drm_vblank_off() gets called 3. drm_wait_vblank() calls drm_queue_vblank_event() which adds the event to the queue event though vblank

[PATCH 08/19] drm: Fix deadlock between event_lock and vbl_lock/vblank_time_lock

From: Ville Syrj?l? Currently both drm_irq.c and several drivers call drm_vblank_put() while holding event_lock. Now that drm_vblank_put() can disable the vblank interrupt directly it may need to grab vbl_lock and vblank_time_lock. That causes deadlocks since we

[PATCH v2 07/19] drm: Reduce the amount of dev->vblank[crtc] in the code

From: Ville Syrj?l? Declare a local struct drm_vblank_crtc * and use that instead of having to do dig it out via 'dev->vblank[crtc]' everywhere. Performed with the following coccinelle incantation, and a few manual whitespace cleanups: @@ identifier func,member;

[PATCH 06/19] drm: Avoid random vblank counter jumps if the hardware counter has been reset

From: Ville Syrj?l? When drm_vblank_on() is called the hardware vblank counter may have been reset, so we can't trust that the old values sampled prior to drm_vblank_off() have anything to do with the new values. So update the .last count in drm_vblank_on() to

[PATCH 05/19] drm: Have the vblank counter account for the time between vblank irq disable and drm_vblank_off()

From: Ville Syrj?l? If the vblank irq has already been disabled (via the disable timer) when we call drm_vblank_off() sample the counter and timestamp one last time. This will make the sure that the user space visible counter will account for time between vblank

[PATCH 04/19] drm: Move drm_update_vblank_count()

From: Ville Syrj?l? Move drm_update_vblank_count() to avoid forward a declaration. No functional change. Reviewed-by: Matt Roper Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_irq.c | 128 +++--- 1 file changed, 64

[PATCH 03/19] drm: Don't clear vblank timestamps when vblank interrupt is disabled

From: Ville Syrj?l? Clearing the timestamps causes us to send zeroed timestamps to userspace if they get sent out in response to the drm_vblank_off(). It's better to send the very latest timestamp and count instead. Testcase: igt/kms_flip/modeset-vs-vblank-race

[PATCH v2 02/19] drm/i915: Warn if drm_vblank_get() still works after drm_vblank_off()

From: Ville Syrj?l? v2: Drop the drm_vblank_off() (Daniel) Use drm_crtc_vblank_{get,put}() Reviewed-by: Matt Roper Reviewed-by: Daniel Vetter Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/i915/intel_display.c | 10 ++ 1 file changed, 10

[PATCH v2 01/19] drm: Always reject drm_vblank_get() after drm_vblank_off()

From: Ville Syrj?l? Make sure drm_vblank_get() never succeeds when called between drm_vblank_off() and drm_vblank_on(). Borrow a trick from the old drm_vblank_{pre,post}_modeset() functions and just bump the refcount in drm_vblank_off() and drop it in

[PATCH v2 00/19] drm: More vblank on/off work

From: Ville Syrj?l? This is mostly a repost of the earlier series [1]. Most of the patches have been reviewed, but I have added quite a few new ones to the end to fix various issues. [1] http://lists.freedesktop.org/archives/dri-devel/2014-May/060518.html Ville

[PATCH] video/fbdev: Always built-in video= cmdline parsing

On Wed, Aug 06, 2014 at 12:27:32PM +0200, Geert Uytterhoeven wrote: > On Wed, Aug 6, 2014 at 11:43 AM, Daniel Vetter > wrote: > > In drm/i915 we want to get at the video= cmdline modes even when we > > don't have fbdev support enabled, so that users can always override > > the kernel's initial

[Bug 82162] Syslog flooded by [drm:radeon_gem_object_create] errors

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

[PATCH 2/5] drm/radeon: add userptr flag to limit it to anonymous memory v2

On Wed, Aug 06, 2014 at 02:34:16PM -0400, Jerome Glisse wrote: > On Wed, Aug 06, 2014 at 07:17:25PM +0200, Christian K?nig wrote: > > Am 06.08.2014 um 18:08 schrieb Jerome Glisse: > > >On Wed, Aug 06, 2014 at 08:55:28AM +0200, Christian K?nig wrote: > > >>Am 06.08.2014 um 00:13 schrieb Jerome

[PATCH] drm: Don't grab an fb reference for the idr

On Wed, Aug 06, 2014 at 07:11:28AM -0400, Rob Clark wrote: > On Wed, Aug 6, 2014 at 3:10 AM, Daniel Vetter > wrote: > > The current refcounting scheme is that the fb lookup idr also holds a > > reference. This works out nicely bacause thus far we've always > > explicitly cleaned up idr entries

[PATCH 2/5] drm/radeon: add userptr flag to limit it to anonymous memory v2

On Wed, Aug 06, 2014 at 07:17:25PM +0200, Christian K?nig wrote: > Am 06.08.2014 um 18:08 schrieb Jerome Glisse: > >On Wed, Aug 06, 2014 at 08:55:28AM +0200, Christian K?nig wrote: > >>Am 06.08.2014 um 00:13 schrieb Jerome Glisse: > >>>On Tue, Aug 05, 2014 at 07:45:21PM +0200, Christian K?nig

[Bug 82162] Syslog flooded by [drm:radeon_gem_object_create] errors

scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140806/078cdbef/attachment.html>

[PATCH] video/fbdev: Always built-in video= cmdline parsing

In drm/i915 we want to get at the video= cmdline modes even when we don't have fbdev support enabled, so that users can always override the kernel's initial mode selection. But that gives us a direct depency upon the parsing code in the fbdev subsystem. Since it's so little code just extract

[PATCH 2/2] drm/i915: Free pending page flip events at .preclose()

From: Ville Syrj?l? If there are pending page flips when the fd gets closed those page flips may have events associated to them. When the page flip eventually completes it will queue the event to file_priv->event_list, but that may be too late and

[PATCH 1/2] drm: Warn when leaking flip events on close

From: Ville Syrj?l? Warn when there are events on the file_priv->event_list just before file_priv gets freed. This can occur if the driver doesn't clean up pending page flip events in ->preclose(). Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_fops.c | 2

[PATCH 2/3] drm: Fix emitted vblank timestamps in drm_vblank_off()

On Wed, Aug 06, 2014 at 03:22:45AM +0200, Mario Kleiner wrote: > Move the query for vblank count and time before the > vblank_disable_and_save(), because the disable fn > will invalidate the vblank timestamps, so all emitted > events would carry an invalid zero timestamp instead of > the timestamp

[PATCH 1/3] drm: Remove drm_vblank_cleanup from drm_vblank_init error path.

On Wed, Aug 06, 2014 at 03:22:44AM +0200, Mario Kleiner wrote: > drm_vblank_cleanup() would operate on non-existent dev->vblank > data structure, as failure to allocate that data structure is > what triggers the error path in the first place. > > Signed-off-by: Mario Kleiner > Cc: stable at

[PATCH 3/3] drm: Use vblank_disable_and_save in drm_vblank_cleanup()

On Wed, Aug 06, 2014 at 03:22:46AM +0200, Mario Kleiner wrote: > Calling vblank_disable_fn() will cause that function to no-op > if !dev->vblank_disable_allowed for some kms drivers, e.g., > on nouveau-kms. This can cause the gpu vblank irq's to not get > disabled before freeing the dev->vblank

[PATCH 6/6] drm: Resetting rotation property

From: Sonika Jindal Reset rotation property to 0. v2: Resetting after disabling the plane Cc: dri-devel at lists.freedesktop.org Signed-off-by: Sonika Jindal Reviewed-by: Ville Syrj?l? --- drivers/gpu/drm/drm_fb_helper.c |9 - 1 file changed, 8

[PATCH] drm: idiot-proof vblank

After spending slightly more time than I'd care to admit debugging the various and presumably spectacular way things fail when you pass too low a value to drm_vblank_init() (thanks console-lock for not letting me see the carnage!), I decided it might be a good idea to add some sanity checking.

[Bug 42878] black flash every time pm changes clocks

dri-devel/attachments/20140806/ed83531e/attachment.html>

[PATCH] video/fbdev: Always built-in video= cmdline parsing

On Wed, Aug 6, 2014 at 11:43 AM, Daniel Vetter wrote: > In drm/i915 we want to get at the video= cmdline modes even when we > don't have fbdev support enabled, so that users can always override > the kernel's initial mode selection. > > But that gives us a direct depency upon the parsing code in

[PATCH 2/5] drm/radeon: add userptr flag to limit it to anonymous memory v2

On Wed, Aug 06, 2014 at 08:55:28AM +0200, Christian K?nig wrote: > Am 06.08.2014 um 00:13 schrieb Jerome Glisse: > >On Tue, Aug 05, 2014 at 07:45:21PM +0200, Christian K?nig wrote: > >>Am 05.08.2014 um 19:39 schrieb Jerome Glisse: > >>>On Tue, Aug 05, 2014 at 06:05:29PM +0200, Christian K?nig

[PATCH] video/fbdev: Always built-in video= cmdline parsing

In drm/i915 we want to get at the video= cmdline modes even when we don't have fbdev support enabled, so that users can always override the kernel's initial mode selection. But that gives us a direct depency upon the parsing code in the fbdev subsystem. Since it's so little code just extract

[PATCH 4/5] drm/radeon: add userptr flag to register MMU notifier v3

On Tue, Aug 05, 2014 at 06:05:31PM +0200, Christian K?nig wrote: > From: Christian K?nig > > Whenever userspace mapping related to our userptr change > we wait for it to become idle and unmap it from GTT. > > v2: rebased, fix mutex unlock in error path > v3: improve commit message Why in hell

[Intel-gfx] [PATCH 1/6] drm: Renaming DP training vswing/pre-emph defines

On 8/5/2014 6:00 PM, Daniel Vetter wrote: > On Tue, Aug 5, 2014 at 1:33 PM, Jindal, Sonika > wrote: >> >> >> On 8/5/2014 4:45 PM, Daniel Vetter wrote: >>> >>> On Tue, Aug 05, 2014 at 04:38:17PM +0530, sonika.jindal at intel.com wrote: From: Sonika Jindal Renaming defines

[PATCH 1/6] drm: Renaming DP training vswing/pre-emph defines

On Tuesday, August 05, 2014 8:08 PM, Sonika Jindal wrote: > > From: Sonika Jindal > > Renaming defines to have levels instead of nominal values. (+cc Daniel Vetter) Hi Sonika Jindal, Thank you for sending the patch. However, please add the reason to this commit message, as you said at

  1   2   >