[PATCH 4/4] drm/nouveau: introduce CPU cache flushing macro

On Mon, Jun 9, 2014 at 7:41 PM, Alexandre Courbot wrote: > On Mon, May 19, 2014 at 6:22 PM, Lucas Stach > wrote: >> Am Montag, den 19.05.2014, 11:02 +0200 schrieb Thierry Reding: >>> On Mon, May 19, 2014 at 04:10:58PM +0900, Alexandre Courbot wrote: >>> > Some architectures (e.g. ARM) need the

[Bug 77751] New: radeon: unable to set temperature warning levels

https://bugzilla.kernel.org/show_bug.cgi?id=77751 Bug ID: 77751 Summary: radeon: unable to set temperature warning levels Product: Drivers Version: 2.5 Kernel Version: 3.15 Hardware: All OS: Linux Tree:

[Bug 74911] [R9 270X] - Frozen display output and no response from keyboard right after loading kernel image and initramfs

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

[PATCH 1/2] drm/panel: remove unnecessary dependencies

On Thursday 12 June 2014 17:04:34 Russell King - ARM Linux wrote: > > In which case, that's a bug for DRM_PANEL_SIMPLE which uses the same > mechanism. Since everything is going to be in the same boat, the > menu should depend on DRM && DRM_PANEL. > Right, I actually have a patch for

[PATCH 2/2] drm/panel: make DRM_PANEL_LD9040 depend on SPI

On Thursday 12 June 2014 16:50:20 Russell King wrote: > Rather than DRM_PANEL_LD9040 selecting SPI, which then results in an > increase in the probability of Kconf reporting circular dependencies > (we're one "select" away from that right now), make this depend on > SPI instead. This is akin to

[PATCH 1/2] drm/panel: remove unnecessary dependencies

On Thursday 12 June 2014 16:50:15 Russell King wrote: > DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on > DRM_PANEL && DRM. This is nonsense for two reasons: > > (a) DRM_PANEL already depends on DRM, so DRM_PANEL can not be enabled > without DRM first being enabled. Hence the

[Bug 79756] [Radeon] Resizing Steam windows freezes Xorg

- 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/20140612/fbedac9b/attachment.html>

[PATCH] drm: imx: use GENERIC_IRQ_CHIP

On Thursday 12 June 2014 16:04:19 Russell King - ARM Linux wrote: > On Thu, Jun 12, 2014 at 04:51:26PM +0200, Arnd Bergmann wrote: > > On Thursday 12 June 2014 15:23:54 Russell King - ARM Linux wrote: > > > On Thu, Jun 12, 2014 at 04:05:32PM +0200, Arnd Bergmann wrote: > > > > This driver defines

[PATCH v2 2/2] drm/panel: make DRM_PANEL_LD9040 depend on SPI

Rather than DRM_PANEL_LD9040 selecting SPI, which then results in an increase in the probability of Kconf reporting circular dependencies (we're one "select" away from that right now), make this depend on SPI instead. This is akin to having some driver select DRM. Having some drivers depend on a

[PATCH v2 1/2] drm/panel: remove unnecessary dependencies

DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on DRM_PANEL && DRM. This is nonsense for two reasons: (a) DRM_PANEL already depends on DRM, so DRM_PANEL can not be enabled without DRM first being enabled. Hence the && DRM is useless. (b) These two configs are already beneath a

[PATCH] drm/panel: add support for Innolux N156BGE-L21 panel

This panel is used by the Medcom Wide and supported by the simple-panel driver. Signed-off-by: Alban Bedel --- drivers/gpu/drm/panel/panel-simple.c | 25 + 1 file changed, 25 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c

[PATCH 1/2] drm/panel: remove unnecessary dependencies

On Thu, Jun 12, 2014 at 06:00:07PM +0200, Arnd Bergmann wrote: > On Thursday 12 June 2014 16:50:15 Russell King wrote: > > DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on > > DRM_PANEL && DRM. This is nonsense for two reasons: > > > > (a) DRM_PANEL already depends on DRM, so

[PATCH] drm: imx: use GENERIC_IRQ_CHIP

On Thursday 12 June 2014 15:23:54 Russell King - ARM Linux wrote: > On Thu, Jun 12, 2014 at 04:05:32PM +0200, Arnd Bergmann wrote: > > This driver defines its own irqchip using the generic chip > > infrastructure, and hence needs the GENERIC_IRQ_CHIP Kconfig > > symbol enabled, or get this build

[PATCH 2/2] drm/panel: make DRM_PANEL_LD9040 depend on SPI

Rather than DRM_PANEL_LD9040 selecting SPI, which then results in an increase in the probability of Kconf reporting circular dependencies (we're one "select" away from that right now), make this depend on SPI instead. This is akin to having some driver select DRM. Having some drivers depend on a

[PATCH 1/2] drm/panel: remove unnecessary dependencies

DRM_PANEL_LD9040 and DRM_PANEL_S6E8AA0 both explicitly depended on DRM_PANEL && DRM. This is nonsense for two reasons: (a) DRM_PANEL already depends on DRM, so DRM_PANEL can not be enabled without DRM first being enabled. Hence the && DRM is useless. (b) These two configs are already beneath a

[PATCH] drm: imx: use GENERIC_IRQ_CHIP

This driver defines its own irqchip using the generic chip infrastructure, and hence needs the GENERIC_IRQ_CHIP Kconfig symbol enabled, or get this build error: drivers/built-in.o: In function `ipu_probe': :(.text+0x49ea4c): undefined reference to `irq_generic_chip_ops' :(.text+0x49ea5c):

[PATCH] drm: imx: use GENERIC_IRQ_CHIP

On Thu, Jun 12, 2014 at 04:51:26PM +0200, Arnd Bergmann wrote: > On Thursday 12 June 2014 15:23:54 Russell King - ARM Linux wrote: > > On Thu, Jun 12, 2014 at 04:05:32PM +0200, Arnd Bergmann wrote: > > > This driver defines its own irqchip using the generic chip > > > infrastructure, and hence

[PATCH] drm: imx: use GENERIC_IRQ_CHIP

On Thu, Jun 12, 2014 at 04:05:32PM +0200, Arnd Bergmann wrote: > This driver defines its own irqchip using the generic chip > infrastructure, and hence needs the GENERIC_IRQ_CHIP Kconfig > symbol enabled, or get this build error: > > drivers/built-in.o: In function `ipu_probe': >

[Bug 79696] 10.2.0rc5 GPU stall & Xorg crash while using Geeqie

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/20140612/aff4b0e3/attachment-0001.html>

[PATCH 1/3] drm/radeon: stop poisoning the GART TLB

Please do so, and you might want to try 3.15.0 as well. I've tested multiple piglit runs over night with my Bonaire and 3.15.0 and that seemed to work perfectly fine. Going to test Alex drm-next-3.16 a bit more as well. Christian. Am 11.06.2014 12:56, schrieb Marek Ol??k: > I only tested

[PATCH 3/4] drm/tegra: Add SET/GET_FLAGS IOCTLs

able to return is -EINVAL for ioctls, which is completely > pointless. I disagree. -EINVAL makes perfect sense because one of the arguments passed into the IOCTL (the handle) is invalid. > So my approach is to throw the vfs experts opinion into the wind and > continue with the well-e

[git pull] drm merge tree

On Thu, Jun 12, 2014 at 12:06 PM, Linus Torvalds wrote: > > I just had the machine reboot on me when booting this and starting X, > leaving nothing in the logs. Ok, I can't recreate it, and as such I can't be sure that it was even the drm merge that causes it (although the timing was

[git pull] drm merge tree

On Wed, Jun 11, 2014 at 5:58 PM, Dave Airlie wrote: > > This is the main drm merge window pull request, changes all over the place, > mostly normal levels of churn. Hmm. I just had the machine reboot on me when booting this and starting X, leaving nothing in the logs. This is on a

[PATCH 3/4] drm/tegra: Add SET/GET_FLAGS IOCTLs

On Thu, Jun 12, 2014 at 09:18:40AM +0200, Thierry Reding wrote: > On Wed, Jun 11, 2014 at 09:21:21AM -0700, St?phane Marchesin wrote: > > On Tue, Jun 10, 2014 at 4:04 AM, Thierry Reding > > wrote: > > > From: Thierry Reding > > > > > > The DRM_TEGRA_GEM_SET_FLAGS IOCTL can be used to set the

[RFC PATCH] nouveau: rename aux.c to auxiliary.c for reviewing it on Windows

On 06/11/2014 04:24 PM, Borislav Petkov wrote: > On Wed, Jun 11, 2014 at 03:53:55PM +0800, Lai Jiangshan wrote: >> When I tried to review the linux kernel on Windows in my laptop >> and incidentally found that it failed to open the aux.c. >> >> And Microsoft tells me: >>

[RFC PATCH] nouveau: rename aux.c to auxiliary.c for reviewing it on Windows

On 06/11/2014 04:24 PM, Borislav Petkov wrote: > On Wed, Jun 11, 2014 at 03:53:55PM +0800, Lai Jiangshan wrote: >> When I tried to review the linux kernel on Windows in my laptop >> and incidentally found that it failed to open the aux.c. >> >> And Microsoft tells me: >>

[PATCH 01/11] vga_switcheroo: Add support for switching only the DDC

On 2 June 2014 02:38, Matthew Garrett wrote: > From: Seth Forshee > > During graphics driver initialization its useful to be able to mux only > the DDC to the inactive client in order to read the EDID. Add a > switch_ddc callback to allow capable handlers to provide this > functionality, and add

[Bug 79756] [Radeon] Resizing Steam windows freezes Xorg

u 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/20140612/38fe3877/attachment.html>

[patch] gma500: out of bounds read in debug code comma

The code assume that this array has 32 elements but because of a missing comma, then it only has 31. This array is only used when error occurs and debugging is enabled so it's not very serious. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c

[RESEND PATCH] vgaarb: We can own non-decoded resources

The VGA arbiter does not allow devices to "own" resources that it doesn't "decode". However, it does allow devices to "lock" resources that it doesn't decode. This gets us into trouble because locking the resource goes through the same bridge routing updates regardless of whether we decode the

[Bug 79696] 10.2.0rc5 GPU stall & Xorg crash while using Geeqie

<http://lists.freedesktop.org/archives/dri-devel/attachments/20140612/7d1f5a39/attachment.html>

[PATCH 3/4] drm/tegra: Add SET/GET_FLAGS IOCTLs

used *a lot* in DRM (many, if not most, of the instances returning the error from an IOCTL), I wonder how this can be resolved. Given that userspace may rely on this error code and that we can't break userspace I don't see a way out. Thierry [0]: https://lkml.org/lkml/2012/12/23/75 -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140612/94537cec/attachment-0001.sig>

[PATCH 2/4] drm/tegra: Add SET/GET_TILING IOCTLs

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

[PATCH] drm/cirrus: bind also to qemu-xen-traditional

Ping? On Fri, Apr 11, Olaf Hering wrote: > qemu as used by xend/xm toolstack uses a different subvendor id. > Bind the drm driver also to this emulated card. > > Signed-off-by: Olaf Hering > --- > drivers/gpu/drm/cirrus/cirrus_drv.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git

[Bug 79850] [awesomenauts][radeonsi] pageflip is clearly missing vblank with vsync on

of its conditions are not met. -- 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/20140612/49320ee5/attachment.html>

[Bug 79756] [Radeon] Resizing Steam windows freezes Xorg

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

[Bug 79696] 10.2.0rc5 GPU stall & Xorg crash while using Geeqie

thing anymore. Would that really be an improvement? -- 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/20140612/c516bdef/attachment.html>

[git pull] drm merge tree

Hi Linus, This is the main drm merge window pull request, changes all over the place, mostly normal levels of churn. Highlights: drm: more cleanups, fix race on connector/encoder naming, docs updates, object locking rework in prep for atomic modeset i915: mipi DSI support, valleyview

[Bug 78717] radeon: Failed to allocate a buffer with Tesseract

eed to specify radeon.gartsize=1024 or larger on the kernel command line. -- 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

[PATCH V4 10/10] drm/exynos: Add ps8622 lvds bridge discovery to DP driver

From: Rahul Sharma This patch adds ps8622 lvds bridge discovery code to the dp driver. Signed-off-by: Rahul Sharma Signed-off-by: Ajay Kumar --- drivers/gpu/drm/exynos/exynos_dp_core.c |5 + 1 file changed, 5 insertions(+) diff --git

[PATCH V4 09/10] drm/bridge: Add ps8622/ps8625 bridge driver

From: Vincent Palatin This patch adds drm_bridge driver for parade DisplayPort to LVDS bridge chip. Signed-off-by: Vincent Palatin Signed-off-by: Andrew Bresticker Signed-off-by: Sean Paul Signed-off-by: Rahul Sharma Signed-off-by: Ajay Kumar ---

[PATCH V4 08/10] drm/exynos: dp: create bridge chain using ptn3460 and panel_binder

exynos_dp supports a simple bridge chain with ptn3460 bridge and an LVDS panel attached to it. This patch creates the bridge chain with ptn3460 as the head of the list and panel_binder being the tail. Signed-off-by: Ajay Kumar --- drivers/gpu/drm/exynos/exynos_dp_core.c | 12 +++- 1

[PATCH V4 07/10] drm/bridge: ptn3460: Support bridge chaining

Modify the driver to invoke callbacks for the next bridge in the bridge chain. Also, remove the drm_connector implementation from ptn3460, since the same is implemented using panel_binder. Signed-off-by: Ajay Kumar --- drivers/gpu/drm/bridge/ptn3460.c| 136

[PATCH V4 06/10] drm/bridge: Add a driver which binds drm_bridge with drm_panel

Add a dummy bridge which binds all of the drm_bridge callbacks to corresponding drm_panel callbacks. In theory, this is just a glue layer for the last bridge and the panel attached to it. This driver also implements the required drm_connector ops for the encoder(on which the entire bridge chain

[PATCH V4 05/10] drm/bridge: add helper functions to support bridge chain

Add helper functions to create bridge chain and to call the corresponding next_bridge functions. Signed-off-by: Ajay Kumar Suggested-by: Rob Clark --- include/drm/drm_crtc.h | 72 1 file changed, 72 insertions(+) diff --git

[PATCH V4 04/10] drm/panel: Add driver for lvds/edp based panels

This patch adds a simple driver to handle all the LCD and LED powerup/down routines needed to support eDP/LVDS panels. The LCD and LED units are usually powered up via regulators, and almost on all boards, we will have a BACKLIGHT_EN pin to enable/ disable the backlight. Sometimes, we can have

[PATCH V4 03/10] drm/exynos: dp: modify driver to support drm_panel

Add drm_panel controls to support powerup/down of the eDP panel, if one is present at the sink side. Signed-off-by: Ajay Kumar --- .../devicetree/bindings/video/exynos_dp.txt|2 + drivers/gpu/drm/exynos/Kconfig |1 + drivers/gpu/drm/exynos/exynos_dp_core.c

[PATCH V4 02/10] drm/panel: add prepare and unprepare routines

Most of the panels need an init sequence as mentioned below: -- poweron LCD unit/LCD_EN -- start video data -- poweron LED unit/BACKLIGHT_EN And, a de-init sequence as mentioned below: -- poweroff LED unit/BACKLIGHT_EN -- stop video data -- poweroff

[PATCH V4 01/10] drm/exynos: Move DP setup out of hotplug workqueue

Move the DP training and video enable from the hotplug handler into a seperate function and call the same during dpms ON. With existing code, DP HPD should be generated just few ms before calling enable_irq in dp_poweron. This patch removes that stringent time constraint. Signed-off-by: Ajay

[PATCH V4 00/10] drm: exynos: few patches to enhance bridge chip support

This series is based on exynos-drm-next branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git I have tested this after adding few DT changes for exynos5250-snow, exynos5420-peach-pit and exynos5800-peach-pi boards. This patchset also consolidates

[Bug 76223] [radeonsi] luxmark segfault

https://bugs.freedesktop.org/show_bug.cgi?id=76223 --- Comment #7 from Aaron Watry --- I've sent a whole bunch of patches to the libclc dev list implementing quite a few builtin CL functions that were missing. luxrays/slg4 is now able to compile the CL kernels, but it now gets an LLVM Error at