[Bug 88669] clover on radeonsi fails in radeon_shader_binary_config_start

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/651df3a5/attachment.html>

drm: exynos: mixer: fix using usleep() in atomic context

Hello! Inki Dae wrote: > The use of spin lock, reg_slock, has been used for a long time and we > hadn't some cleanups to spin lock codes so far. The spin lock is also > used in here and there of mixer driver. And at least, it seems that > the use of spin lock isn't required in mixer_win_reset. I

[Bug 88669] clover on radeonsi fails in radeon_shader_binary_config_start

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20150121/889454b9/attachment.html>

[drm/ttm] Memory corruption problem when ttm_tt_init() fails.

I'm doing memory allocation failure injection test using 3.19-rc5 and it seems to me that there is a memory corruption bug in ttm or vmwgfx code. -- Crash pattern 1 start -- [ 80.751971] [TTM] Failed allocating page table [ 83.000393] BUG: unable to handle kernel NULL pointer

[drm-intel:drm-intel-nightly 357/550] drivers/gpu/drm/radeon/cik_sdma.c:293:6: sparse: symbol 'cik_sdma_ctx_switch_enable' was not declared. Should it be static?

tree: git://anongit.freedesktop.org/drm-intel drm-intel-nightly head: 0e3c37cedf582819b6dbdd0bf0b14a15d3c2e47d commit: d7a60d8ea5cd4560e0496d2683643d2e4930e609 [357/550] drm/radeon: Enable sdma preemption reproduce: # apt-get install sparse git checkout

[PATCH drm-intel] drm/radeon: cik_sdma_ctx_switch_enable() can be static

drivers/gpu/drm/radeon/cik_sdma.c:293:6: sparse: symbol 'cik_sdma_ctx_switch_enable' was not declared. Should it be static? Signed-off-by: Fengguang Wu --- cik_sdma.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/cik_sdma.c

[PATCH v2] drm/i2c: tda998x: Set the CEC I2C address based on the slave I2C address.

On Wed, Jan 21, 2015 at 06:46:58PM +, Russell King - ARM Linux wrote: > On Wed, Jan 21, 2015 at 06:44:05PM +, Liviu Dudau wrote: > > On Fri, Nov 07, 2014 at 08:31:25AM +, Andrew Jackson wrote: > > > The I2C address for the TDA9989 and TDA19989 is fixed at 0x34 > > > but the two LSBs of

[PATCH v2] drm/i915: fix inconsistent brightness after resume

On Mon, 12 Jan 2015, Jeremiah Mahler wrote: > Commit 6dda730e55f4 introduced a bug which resulted in inconsistent > brightness levels on different machines. If a suspended was entered > with the screen off some machines would resume with the screen > at minimum brightness and others at maximum

[RFCv2 1/2] device: add dma_params->max_segment_count

Hi Sumit, On 21/01/15 04:16, Sumit Semwal wrote: > From: Rob Clark > > For devices which have constraints about maximum number of segments in > an sglist. For example, a device which could only deal with contiguous > buffers would set max_segment_count to 1. > > The initial motivation is for

[PATCH v3] drm: imx: imx-tve: Check and propagate the errors

Am Dienstag, den 20.01.2015, 20:44 -0200 schrieb Fabio Estevam: > From: Fabio Estevam > > In the case of errors we should propagate them. > > Signed-off-by: Fabio Estevam > --- > Changes since v2: > - Propage the error in more places like suggested by Philipp Thank you, I have queued this

[PATCH v2] drm/i2c: tda998x: Set the CEC I2C address based on the slave I2C address.

On Wed, Jan 21, 2015 at 06:44:05PM +, Liviu Dudau wrote: > On Fri, Nov 07, 2014 at 08:31:25AM +, Andrew Jackson wrote: > > The I2C address for the TDA9989 and TDA19989 is fixed at 0x34 > > but the two LSBs of the TDA19988's address are set by two configuration > > pins on the chip.

[PATCH v2] drm/i2c: tda998x: Set the CEC I2C address based on the slave I2C address.

On Fri, Nov 07, 2014 at 08:31:25AM +, Andrew Jackson wrote: > The I2C address for the TDA9989 and TDA19989 is fixed at 0x34 > but the two LSBs of the TDA19988's address are set by two configuration > pins on the chip. Irrespective of the chip, the associated CEC > peripheral's I2C address is

[PATCH 2/2] dma-buf/fence: don't wait when specified timeout is zero

When specified timeout is zero for fence_wait_timeout, just check if the fence is signaled or not without wait. Signed-off-by: Jammy Zhou --- drivers/dma-buf/fence.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma-buf/fence.c b/drivers/dma-buf/fence.c index e554111..50ef8bd

[PATCH 1/2] reservation: wait only with non-zero timeout specified (v3)

When the timeout value passed to reservation_object_wait_timeout_rcu is zero, no wait should be done if the fences are not signaled. Return '1' for idle and '0' for busy if the specified timeout is '0' to keep consistent with the case of non-zero timeout. v2: call fence_put if not signaled in

[Bug 77002] hdmi audio problems with 3.14

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/69d317f2/attachment.html>

[PATCH 1/2] reservation: wait only with non-zero timeout specified (v3)

Hey, On 21-01-15 17:16, Alex Deucher wrote: > On Wed, Jan 21, 2015 at 5:31 AM, Maarten Lankhorst > wrote: >> Op 21-01-15 om 11:35 schreef Jammy Zhou: >>> When the timeout value passed to reservation_object_wait_timeout_rcuy, >>> is zero, no wait should be done if the fences are not signaled. >>>

[Bug 90741] Radeon: System pauses on TAHITI

https://bugzilla.kernel.org/show_bug.cgi?id=90741 --- Comment #16 from Gustaw Smolarczyk --- Unfortunately, the last patch doesn't seem to help in any way. Should I test the other two too? -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH] drm/radeon: make MMU_NOTIFIER optional

In cases where MMU_NOTIFIER is not available, userptr will not be available. Similar to i915, although not making an exception for CAP_SYS_ADMIN. The proposed userspace patches for userptr seem to handle the fall- back properly, so a userptr-less kernel should not be a problem. Signed-off-by:

[PATCH 3/3] drm/radeon: Remove rdev->gart.pages_addr array

From: Michel Dänzer radeon_vm_map_gart can use rdev->gart.pages_entry instead. Also move the masking of the page address to radeon_vm_map_gart from its callers. Signed-off-by: Michel Dänzer --- drivers/gpu/drm/radeon/cik_sdma.c| 1 -

[PATCH 2/3] drm/radeon: Reinstate radeon_gart_restore for GART table in VRAM

From: Michel Dänzer The GART table BO has to be moved out of VRAM for suspend/resume. Any updates to the GART table during that time were silently dropped without this change. This caused GPU lockups on resume in some cases, see the bug reports referenced below. This

[PATCH 1/3] drm/radeon: Split off gart_get_page_entry ASIC hook from set_page_entry

From: Michel Dänzer get_page_entry calculates the GART page table entry, which is just written to the GART page table by set_page_entry. This is a prerequisite for the following fix. Cc: stable at vger.kernel.org Signed-off-by: Michel Dänzer ---

[RFCv2 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

On Wed, Jan 21, 2015 at 09:46:47AM +0530, Sumit Semwal wrote: > +static int calc_constraints(struct device *dev, > + struct dma_buf_constraints *calc_cons) > +{ > + struct dma_buf_constraints cons = *calc_cons; > + > + cons.dma_mask &= dma_get_mask(dev); I don't

[PATCH v2] clk: Introduce clk_has_parent()

From: Thierry Reding This new function is similar to clk_set_parent(), except that it doesn't actually change the parent. It merely checks that the given parent clock can be a parent for the given clock. A situation where this is useful is to check that a particular setup is

[Bug 88669] clover on radeonsi fails in radeon_shader_binary_config_start

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/20150121/63b9e90e/attachment.html>

[PATCH 2/4] drm/atomic: Add drm_crtc_state->active

Looks basically sane.. you have a branch on top of drm-next w/ this patchset somewhere? There is enough to it that I probably need to actually try it out and see what explodes ;-) couple minor comments below On Tue, Jan 20, 2015 at 5:09 PM, Daniel Vetter wrote: [snip] > diff --git

[RFC v3 4/4] drm/i915: Enable DSI panel enable/disable based on PMIC

This allows for proper PPS during enable/disable of BYT-T platforms where these signals are routed through PMIC. Needs DRM_PANEL to be selected by default as well v2: Adapt to panel find function name change in drm_panel Signed-off-by: Shobhit Kumar --- drivers/gpu/drm/i915/Kconfig

[RFC v3 3/4] drm/i915: Add new panel driver based on crystal cove pmic

This driver provides support for the "crystal_cove_panel" cell device. On BYT-T pmic has to be used to enable/disable panel. v2: Addressed Jani's comments - Moved inside i915 - Correct licensing - Remove unused stuff - Do not initialize prepare/unprepare as they are not needed as

[RFC v3 2/4] mfd: Add a new cell device for panel controlled by crystal cove pmic

On BYT-T configuration, panel enable/disable signals are routed through PMIC. Add a cell device for the same. Signed-off-by: Shobhit Kumar --- drivers/mfd/intel_soc_pmic_crc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mfd/intel_soc_pmic_crc.c

[RFC v3 1/4] drm: Add support to find drm_panel by name

For scenarios where OF is not available, we can use panel identification by name. Signed-off-by: Shobhit Kumar --- drivers/gpu/drm/drm_panel.c | 18 ++ include/drm/drm_panel.h | 3 +++ 2 files changed, 21 insertions(+) diff --git a/drivers/gpu/drm/drm_panel.c

[RFC v3 0/4] Crystal Cove PMIC based Panel and Backlight Control

Hi All Please find modifed set of patches using regmap interface to accedd the PMIC registers. These patches implement a drm_panel as a platform driver for the mfd_cell device declared in intel_soc_pmic_core.c. DRM is extended to provide a find panel by name in absence of OF. Backlight

[PATCH 2/2] drm/probe-helper: clamp unknown connector status in the poll work

On Wed, Jan 21, 2015 at 2:45 AM, Daniel Vetter wrote: > On some chipset we try to avoid possibly invasive output detection > methods (like load detect which can cause flickering elsewhere) in the > output poll work. Drivers could hence return unknown when a previous > full ->detect call returned

[PATCH] drm/probe-helper: don't lose hotplug event

On Wed, Jan 21, 2015 at 9:41 AM, Daniel Vetter wrote: > There's a race window (small for hpd, 10s large for polled outputs) > where userspace could sneak in with an unrelated connnector probe > ioctl call and eat the hotplug event (since neither the hpd nor the > poll code see a state change). >

[PATCH] drm: Add standardized boolean props

On Wed, Jan 21, 2015 at 2:47 AM, Daniel Vetter wrote: > Not a new type exposed to userspace, just a standard way to create > them since between range, bitmask and enum there's 3 different ways to > pull out a boolean prop. > > Also add the kerneldoc for the recently added new prop types, which >

[PATCH 01/10] drm: Add rotation value to plane state

The rotation property is shared by multiple drivers, so it makes sense to store the rotation value (for atomic-converted drivers) in the common plane state so that core code can eventually access it as well. Cc: dri-devel at lists.freedesktop.org Suggested-by: Daniel Vetter Signed-off-by: Matt

[PATCH v2] clk: Introduce clk_has_parent()

On 01/21/2015 08:13 AM, Thierry Reding wrote: > From: Thierry Reding > > This new function is similar to clk_set_parent(), except that it doesn't > actually change the parent. It merely checks that the given parent clock > can be a parent for the given clock. > > A situation where this is useful

[PATCH 01/36] clk: Introduce clk_try_parent()

next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/f9fcce2d/attachment-0001.sig>

[Bug 88152] 720p and 1080 H.264 videos lock-up on playback with vlc / vdpau on Radeon 3850HD

est Radeon updates to Linus' 3.19.0-rc5, lock-up occurred sooner. -- 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/20150121/67

[PATCH 01/36] clk: Introduce clk_try_parent()

parent() fails. > > + */ > > +int clk_try_parent(struct clk *clk, struct clk *parent); > > The name makes me think of mutex_trylock(), so I immediately think this > tries to set the parent. Perhaps a better name would be > clk_can_have_parent() or clk_has_parent()? clk_has_parent() sounds good to me. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/abc9003e/attachment.sig>

[RFC] drm/msm/hdmi: spurious hpd disconnect workaround

On some (well, maybe just one) HDMI monitor I get a spurious disconnect in the process of lighting up the display. A low-pass filter on HPD events, in the form of leaving the HPD irq disabled for 100ms after the previous HPD irq, seems to do a good job of working around the issue. A somewhat

[PATCH] drm/probe-helper: don't lose hotplug event

There's a race window (small for hpd, 10s large for polled outputs) where userspace could sneak in with an unrelated connnector probe ioctl call and eat the hotplug event (since neither the hpd nor the poll code see a state change). To avoid this, check whether the connector state changes in all

[Bug 88493] No hdmi audio an agd5f 3.20-wip since consolidate audio_get_pin() functions

valid for that. -- 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/20150121/749e9597/attachment.html>

[GIT PULL] TDA998x I2C driver fixes

David, Please incorporate the latest TDA998x I2C driver fixes, which can be found at: git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-tda998x-fixes with SHA1 cfe387572585216ffd452256181a719ca90b529e. This will update the following files: drivers/gpu/drm/i2c/tda998x_drv.c | 52

[Bug 90741] Radeon: System pauses on TAHITI

https://bugzilla.kernel.org/show_bug.cgi?id=90741 Maarten Lankhorst changed: What|Removed |Added Attachment #164131|0 |1 is obsolete|

[Bug 88493] No hdmi audio an agd5f 3.20-wip since consolidate audio_get_pin() functions

tachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/e9c324db/attachment.html>

[PULL] drm-amdkfd-next

Hi Dave, Another pull request for 3.20. drm-amdkfd-next-2015-01-21: - Infrastructure work in amdkfd to prepare for VI support. This work mainly includes separating modules into ASIC-specific functionality, adding new properties that are relevant for VI, making sure that shared code is

[PATCH v10 9/9] ASoC: add generic dt-card support

archives/dri-devel/attachments/20150121/9442eb26/attachment-0001.sig>

[PATCH v2] drm/amdkfd: Allow user to limit only queues per device

This patch replaces the two current amdkfd module parameters with a new one. The current parameters that are being replaced are: - Maximum number of HSA processes - Maximum number of queues per process The new parameter that replaces them is called "Maximum queues per device" This replacement

[PATCH] drm/rockchip: fix dma_alloc_attrs() error check

On 21 January 2015 at 12:43, Daniel Kurtz wrote: > Mark: did you get a chance to fixup the "Reported-by" line? It's not > a bit deal if you didn't. > > Dave: did you pick up this pull request? Did Mark request properly? I was waiting for the fixed reported-by but it isn't that urgent, I'll get

[Bug 88493] No hdmi audio an agd5f 3.20-wip since consolidate audio_get_pin() functions

- 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/20150121/8c732533/attachment.html>

[PATCH 1/2] reservation: wait only with non-zero timeout specified (v3)

On Wed, Jan 21, 2015 at 12:30 PM, Maarten Lankhorst wrote: > Hey, > > On 21-01-15 17:16, Alex Deucher wrote: >> On Wed, Jan 21, 2015 at 5:31 AM, Maarten Lankhorst >> wrote: >>> Op 21-01-15 om 11:35 schreef Jammy Zhou: When the timeout value passed to reservation_object_wait_timeout_rcuy,

[Bug 88493] No hdmi audio an agd5f 3.20-wip since consolidate audio_get_pin() functions

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/9a42018a/attachment.html>

[PATCH 00/72] staging imx-drm new features and fixes

On Fri, Oct 31, 2014 at 6:53 PM, Steve Longerbeam wrote: > Hi, this affects only Freescale imx IPU and imx-drm staging drivers, > except for two patches that affect drm core (patch 53 and 63, see below). > > New features for imx-drm staging driver: > > - Support for multi-display (HDMI and

[ANNOUNCE] libdrm 2.4.59

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adam Cheney (1): Add new DRM_MODE_CONNECTOR and _ENCODER defines Chris Wilson (1): intel: Avoid overcounting fences when emitting self-referential relocs Damien Lespiau (3): intel/skl: Add SKL PCI ids intel/skl: Add gen9 to

[PATCH 2/2] dma-buf/fence: don't wait when specified timeout is zero

Am 21.01.2015 um 11:35 schrieb Jammy Zhou: > When specified timeout is zero for fence_wait_timeout, just check if the fence > is signaled or not without wait. > > Signed-off-by: Jammy Zhou Reviewed-by: Christian König > --- > drivers/dma-buf/fence.c | 3 +++ > 1 file changed, 3

[Bug 91371] UVD not responding error during UVD initialization for AMD 7670M graphics

https://bugzilla.kernel.org/show_bug.cgi?id=91371 Adis Hamzić changed: What|Removed |Added CC||adis at hamzadis.com --- Comment #2 from

[PATCH 2/2] dma-buf/fence: don't wait when specified timeout is zero

Op 21-01-15 om 11:35 schreef Jammy Zhou: > When specified timeout is zero for fence_wait_timeout, just check if the fence > is signaled or not without wait. > > Signed-off-by: Jammy Zhou > Reviewed-By: Maarten Lankhorst

[PATCH 1/2] reservation: wait only with non-zero timeout specified (v3)

Op 21-01-15 om 11:35 schreef Jammy Zhou: > When the timeout value passed to reservation_object_wait_timeout_rcu > is zero, no wait should be done if the fences are not signaled. > > Return '1' for idle and '0' for busy if the specified timeout is '0' > to keep consistent with the case of non-zero

[PATCH 1/2] reservation: wait only with non-zero timeout specified (v3)

On Wed, Jan 21, 2015 at 5:31 AM, Maarten Lankhorst wrote: > Op 21-01-15 om 11:35 schreef Jammy Zhou: >> When the timeout value passed to reservation_object_wait_timeout_rcu >> is zero, no wait should be done if the fences are not signaled. >> >> Return '1' for idle and '0' for busy if the

[Bug 88493] No hdmi audio an agd5f 3.20-wip since consolidate audio_get_pin() functions

L attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/a3a25907/attachment.html>

[Bug 88658] (bisected) Slow video playback on Kabini

|Kabini |playback on Kabini -- 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/20150121/b50bc2a6/attachment.html>

[PATCH] drm/rockchip: fix dma_alloc_attrs() error check

Mark: did you get a chance to fixup the "Reported-by" line? It's not a bit deal if you didn't. Dave: did you pick up this pull request? Did Mark request properly? On Fri, Jan 9, 2015 at 12:01 PM, Daniel Kurtz wrote: > On Wed, Jan 7, 2015 at 5:27 PM, Daniel Kurtz wrote: >> dma_alloc_attrs()

[Bug 88408] Black screen in Nuclear Dawn

more information BusID "PCI:1:0:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor"Monitor0" SubSection "Display" Viewport 0 0 Depth 1 EndSubSection SubSection "Display" Viewport 0 0 Depth 4 EndSubSection SubSection "Display" Viewport 0 0 Depth 8 EndSubSection SubSection "Display" Viewport 0 0 Depth 15 EndSubSection SubSection "Display" Viewport 0 0 Depth 16 EndSubSection SubSection "Display" Viewport 0 0 Depth 24 EndSubSection EndSection -- 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/20150121/ca1825b6/attachment.html>

[Bug 88408] Black screen in Nuclear Dawn

https://bugs.freedesktop.org/show_bug.cgi?id=88408 --- Comment #15 from Iwo --- Here is glxinfo: [iwo at antec ~]$ glxinfo name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions:

[Bug 88408] Black screen in Nuclear Dawn

URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/db6f77e1/attachment-0001.html>

[Bug 88658] Slow video playback on Kabini

gnee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/29271709/attachment.html>

[GIT PULL] drm: Add Atmel HLCDC driver

Hi Boris, can you update with Thierry's acks and send again, I'll pull it then. Dave. On 17 January 2015 at 01:09, Thierry Reding wrote: > On Fri, Jan 09, 2015 at 04:03:42PM +0100, Boris Brezillon wrote: >> Dave, Thierry, >> >> Here is the pull request for the Atmel HLCDC driver and its >>

[PATCH 2/3] drm/radeon: Reinstate radeon_gart_restore for GART table in VRAM

Am 21.01.2015 um 09:36 schrieb Michel Dänzer: > From: Michel Dänzer > > The GART table BO has to be moved out of VRAM for suspend/resume. Any > updates to the GART table during that time were silently dropped without > this change. This caused GPU lockups on resume in some cases, see the bug >

[Bug 88658] Slow video playback on Kabini

org/archives/dri-devel/attachments/20150121/283178ca/attachment.html>

[PATCH] reservation: wait only with non-zero timeout specified (v3)

Hey, Op 14-01-15 om 03:16 schreef Zhou, Jammy: >>> I think it would be best to leave timeout=0 returning 0. Not handling it >>> differently gives the same semantics as used by fence_wait_time and >>> wait_event_timeout. >>> Are there really many cases in which you don't know if timeout = 0

[Bug 88658] Slow video playback on Kabini

<http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/8e9bc941/attachment.html>

[GIT PULL] drm: Add Atmel HLCDC driver

Hi Dave, Here is the pull request for the Atmel HLCDC driver and its dependencies (some modifications to drm/core and drm/panel to define output bus format). I've added Thierry's acks and rebased on drm-next, let me know if you need something else. Best Regards, Boris The following changes

[Bug 90741] Radeon: System pauses on TAHITI

https://bugzilla.kernel.org/show_bug.cgi?id=90741 Maarten Lankhorst changed: What|Removed |Added Attachment #164121|0 |1 is obsolete|

[RFCv2 2/2] dma-buf: add helpers for sharing attacher constraints with dma-parms

Add some helpers to share the constraints of devices while attaching to the dmabuf buffer. At each attach, the constraints are calculated based on the following: - dma_mask, coherent_dma_mask from struct device, - max_segment_size, max_segment_count, segment_boundary_mask from

[RFCv2 1/2] device: add dma_params->max_segment_count

From: Rob Clark For devices which have constraints about maximum number of segments in an sglist. For example, a device which could only deal with contiguous buffers would set max_segment_count to 1. The initial motivation is for devices sharing buffers via dma-buf, to

[RFCv2 0/2] dma-parms, constraints and helpers for dma-buf

Hello Everyone, Based on review comments received, I've split my earlier patchset on 'dma-buf constraints-enabled allocation' [1] into 2 sets: - first one is this one, to use dma_parms and related parameters from struct device to share constraints, and then to use these constraints in

[PATCH] drm/vmwgfx: Replace the hw mutex with a hw spinlock

On 19 January 2015 at 21:03, Thomas Hellstrom wrote: > Fixes a case where we call vmw_fifo_idle() from within a wait function with > task state !TASK_RUNNING, which is illegal. > > In addition, make the locking fine-grained, so that it is performed once > for every read- and write operation. This

[GIT PULL] fixes for STI drm driver

<http://www.facebook.com/pages/Linaro> | Twitter <http://twitter.com/#!/linaroorg> | Blog <http://www.linaro.org/linaro-blog/> -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/28753478/attachment-0001.html>

[PATCH] reservation: wait only with non-zero timeout specified (v3)

Sure. I will send the patches out later. Regards, Jammy -Original Message- From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com] Sent: Wednesday, January 21, 2015 5:12 PM To: Zhou, Jammy; Daniel Vetter Cc: Koenig, Christian; dri-devel; Deucher, Alexander Subject: Re: [PATCH]

[GIT PULL] fixes for STI drm driver

On 9 January 2015 at 09:18, Dave Airlie wrote: > On 8 December 2014 at 18:45, Benjamin Gaignard > wrote: >> Hello David, >> >> This series of patches fix various issues in STI drm driver. >> Now HDMI i2c adapter could be selected in device tree >> and plug detection doesn't use gpio anymore. >>

[Bug 90741] Radeon: System pauses on TAHITI

https://bugzilla.kernel.org/show_bug.cgi?id=90741 Maarten Lankhorst changed: What|Removed |Added Attachment #163871|0 |1 is obsolete|

[PATCH] drm: Add standardized boolean props

Not a new type exposed to userspace, just a standard way to create them since between range, bitmask and enum there's 3 different ways to pull out a boolean prop. Also add the kerneldoc for the recently added new prop types, which Rob forgot all about. v2: Fixup kerneldoc, spotted by Rob. Cc:

[PATCH 2/2] drm/probe-helper: clamp unknown connector status in the poll work

On some chipset we try to avoid possibly invasive output detection methods (like load detect which can cause flickering elsewhere) in the output poll work. Drivers could hence return unknown when a previous full ->detect call returned a different state. This change will generate a hotplug event,

[PATCH 1/2] drm/probe-helper: don't lose hotplug event

There's a race window (small for hpd, 10s large for polled outputs) where userspace could sneak in with an unrelated connnector probe ioctl call and eat the hotplug event (since neither the hpd nor the poll code see a state change). To avoid this, check whether the connector state changes in all

[PATCH] drm: don't loose HPD events

On Tue, Jan 20, 2015 at 01:03:51PM -0500, Rob Clark wrote: > Since drm_helper_probe_single_connector_modes_merge_bits() and other > places also update connector->status, the output_poll_execute() and/or > drm_helper_hpd_irq_event() logic can get confused and forget to send > a HPD event. > >

[Bug 79980] Random radeonsi crashes

ssues. Please report a new bug for your problem. -- 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/20150121/5c0751fb/attachment.html>

Implement GLX_EXT_buffer_age for DRI2

On 19 January 2015 at 21:00, Chris Wilson wrote: > In order to suport GLX_EXT_buffer_age in DRI2, we need to pass back the > last swap buffer count that the back buffer was defined for. For > simplicity, we can reuse an existing field in the DRI2GetBuffers reply > that is not used by current

[PATCH] drm/vmwgfx: Replace the hw mutex with a hw spinlock

Hi, Dave, It's intended for -fixes. I was just about to send a pull request but got distracted. Thanks, Thomas On 01/21/2015 12:45 AM, Dave Airlie wrote: > On 19 January 2015 at 21:03, Thomas Hellstrom > wrote: >> Fixes a case where we call vmw_fifo_idle() from within a wait function with >>

[Bug 79980] Random radeonsi crashes

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/20150121/47e4120c/attachment.html>

[Bug 79980] Random radeonsi crashes

vel/attachments/20150121/90a2f345/attachment.html>

[Bug 88642] Trilinear sampling on cubemap wrongly sampled at the border of rasterized triangle on HAWAII

it. -- 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/20150121/b230aea8/attachment.html>

[Bug 88642] Trilinear sampling on cubemap wrongly sampled at the border of rasterized triangle on HAWAII

|| -- 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/20150121/6e14fe2d/attachment.html>

[PATCH V8 00/14] drm/exynos: few patches to enhance bridge chip support

Hi, On Monday 19 January 2015 18:05:07 Javier Martinez Canillas wrote: > On 01/19/2015 05:30 PM, Thierry Reding wrote: > >> I know you probably are very busy but it would be great if you can take a > >> look to this series to avoid another kernel release to be missed since > >> we are already at

drm/gma500: oaktrail lvds cleanup fixes

On Thu, Jan 15, 2015 at 3:10 PM, Jan Safrata wrote: > Fixes to allow removal of gma500_gfx module (after frame buffer > console unbind) when used with Atom E6xx gpu chipset. > > The oaktrail_lvds_init() uses i2c_adap only to read edid > and therefore it should call i2c_put_adapter() after. >

[PATCH] drm/gma500: add missing drm_irq_uninstall

On Thu, Jan 15, 2015 at 3:07 PM, Jan Safrata wrote: > psb_driver_unload did not call drm_irq_uninstall causing kernel oops > in modprobe after rmmod gma500_gfx: > > BUG: unable to handle kernel paging request at f858cf08 > IP: [] strcmp+0x13/0x30 > *pdpt = 016ea001 *pde = 36c44067

[Bug 88493] No hdmi audio an agd5f 3.20-wip since consolidate audio_get_pin() functions

bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150121/600e9795/attachment.html>

[git pull] drm fixes

Hi Linus, Just back from LCA + some days off, had some fixes from the past 2 weeks, some amdkfd code removal for a feature that wasn't ready, otherwise just one fix for core helper sleeping, exynos, i915, and radeon fixes. I thought I had some sti fixes but they were already in, and it