[Linaro-mm-sig] [PATCH 5/7] seqno-fence: Hardware dma-buf implementation of fencing (v4)

2013/1/16 Maarten Lankhorst : > Op 16-01-13 07:28, Inki Dae schreef: >> 2013/1/15 Maarten Lankhorst : >>> This type of fence can be used with hardware synchronization for simple >>> hardware that can block execution until the condition >>> (dma_buf[offset] - value) >= 0 has been met. >>> >>> A

[Bug 58839] errors about too many fences printed while playing neverball

number, so that was not caused by this 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/20130124/230a35dc/attachment.html>

[Bug 58840] rendering error with MSAA on HD6850

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

[PATCH] drm/i2c: Add driver for PTN3460 LVDS/DP bridge

On Thu, Jan 24, 2013 at 7:09 PM, Sean Paul wrote: > This patch adds the driver for the PTN3460 LVDS/DP bridge chip. > > The driver allows the EDID emulation to be selected from device tree, > along with specifying the GPIOs driving powerdown and reset pins. > > The chip has a bug in it such that

[Bug 59592] Radeon HD 5670: reproducable GPU lockups with htile enabled

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130124/87a5d6aa/attachment-0001.html>

[Bug 59592] Radeon HD 5670: reproducable GPU lockups since kernel 3.8

... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130124/049f9243/attachment.html>

[pull] radeon drm-fixes-3.8

From: Alex Deucher Hi Dave, Just a few small fixes. The following changes since commit 014b34409fb2015f63663b6cafdf557fdf289628: ttm: on move memory failure don't leave a node dangling (2013-01-21 13:45:23 +1000) are available in the git repository at:

circular locking warning during suspend

On Thu, Jan 24, 2013 at 6:34 PM, Johannes Berg wrote: > Hi, > > I didn't find this reported, but maybe it has been, I didn't search for > too long. I'm using 3.8.0-rc4 (plus wireless bits), and lockdep is > unhappy. Note that I am booting with "no_console_suspend". Patches for the know issues

[PATCH] vgacon/vt: clear buffer attributes when we load a 512 character font

It would be nice to support more than 512 characters when using a graphical console. We should be able to support up to 2048 at least. Dave Airlie wrote: >On Thu, Jan 24, 2013 at 10:18 PM, H. Peter Anvin wrote: >> The characters will morph anyway, it is just a matter off having them

[Mesa-dev] mesa/gles3: dri_util.c:192:10: error: use of undeclared identifier '__DRI_API_GLES3'

On Thu, Jan 24, 2013 at 7:31 PM, Chad Versace wrote: > FYI, > > The enum is defined in mesa iteself at > #MESA_SOURCE/include/GL/internal/dri_interface.h. Your > problem was independent of dri2proto, kernel, drm, etc. I expect > your build environment was accidentally #including the header

[PATCH v2] drm/radeon: Enable DMA_IB_SWAP_ENABLE on big endian hosts.

From: Michel D?nzer Fixes GPU hang during DMA ring IB test. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59672 Signed-off-by: Michel D?nzer --- v2: The patch fixes real GPU hangs, not just spurious ones. Change the commit log accordingly.

[PATCH] drm/radeon: Enable DMA_IB_SWAP_ENABLE on big endian hosts.

From: Michel D?nzer Fixes spurious GPU lockup during DMA ring IB test. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59672 Signed-off-by: Michel D?nzer --- drivers/gpu/drm/radeon/ni.c |8 ++-- drivers/gpu/drm/radeon/r600.c |8 ++-- 2 files

circular locking warning during suspend

Hi, I didn't find this reported, but maybe it has been, I didn't search for too long. I'm using 3.8.0-rc4 (plus wireless bits), and lockdep is unhappy. Note that I am booting with "no_console_suspend". [ 73.320586] == [ 73.320587] [ INFO:

[PATCH] vgacon/vt: clear buffer attributes when we load a 512 character font

On Thu, Jan 24, 2013 at 3:20 PM, H. Peter Anvin wrote: > We should clear this bit presumably on switching either from or to 512-char > mode, since the bit doesn't really make sense either way. Yeah the only problem going from 512-char is that chars above 256 will morph into garbage chars below

[git pull] fbcon locking fixes.

On Thu, Jan 24, 2013 at 5:45 PM, Dave Airlie wrote: > > Okay I've just sent out another fbcon patch to fix the locking harder. > > There was a path going into set_con2fb_path if an fb driver was > already registered, I just pushed the locking out further on anyone > going in there. > > it boots

[Bug 59672] Problems initializing Radeon driver: lockup during IB test

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

[PATCH 16/16] drm/fb-helper: don't sleep for screen unblank when an oopps is in progress

Otherwise the system will burn even brighter and worse, leave the user wondering what's going on exactly. Since we already have a panic handler which will (try) to restore the entire fbdev console mode, we can just bail out. Inspired by a patch from Konstantin Khlebnikov. The callchain leading to

[PATCH 15/16] drm/fb-helper: improve kerneldoc

Now that the fbdev helper interface for drivers is trimmed down, update the kerneldoc for all the remaining exported functions. I've tried to beat the DocBook a bit by reordering the function references a bit into a more sensible ordering. But that didn't work out at all. Hence just extend the

[PATCH 14/16] drm/: simplify ->fb_probe callback

The fb helper lost its support for reallocating an fb completely, so no need to return special success values any more. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/ast/ast_fb.c | 21 +++- drivers/gpu/drm/cirrus/cirrus_fbdev.c | 22 +++--

[PATCH 13/16] drm/fb-helper: streamline drm_fb_helper_single_fb_probe

No need to check whether we've allocated a new fb since we're not always doing that. Also, we always need to register the fbdev and add it to the panic notifier. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_fb_helper.c | 29 +++-- 1 file changed, 15

[PATCH 12/16] drm/fb-helper: directly call set_par from the hotplug handler

The idea behind calling down into the driver's ->fb_probe function on each hotplug seems to be able to reallocate the backing storage (if e.g. a screen with higher resolution gets added). But that requires quite a bit of work in the fb helper itself, since currently we limit new screens to the

[PATCH 11/16] drm/fb-helper: fixup up set_config semantics

While doing the modeset rework for drm/i915 I've noticed that the fb helper is very liberal with the semantics of the ->set_config interface: - It doesn't bother clearing stale modes (e.g. when unpluggint a screen). - It unconditionally sets and the fb, even if no mode will be set on a given

[PATCH 10/16] drm/i915: rip out helper->disable noop functions

Now that the driver is in control of whether it needs to disable everything at take-over or not, we can rip this all out. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_crt.c |1 - drivers/gpu/drm/i915/intel_ddi.c |1 - drivers/gpu/drm/i915/intel_display.c |9

[PATCH 09/16] drm/fb-helper: don't disable everything in initial_config

This should be done in the drivers for two reasons: - it gets in the way of fastboot efforts - it links the fb helpers with the crtc helpers instead of going through the real interface vfuncs, forcing i915 to fake all the ->disable callbacks used by the crtc helper to avoid ugly Oopsen

[PATCH 08/16] drm/tegra: don't set up initial fbcon config twice

drm_fbdev_cma_init does the inital fbcon setup by calling down into drm_fb_helper_initial_config, so no need at all to restore the just set up configuration right away ... Signed-off-by: Daniel Vetter --- drivers/gpu/drm/tegra/fb.c |4 1 file changed, 4 deletions(-) diff --git

[PATCH 07/16] drm/fb-helper: unexport drm_fb_helper_single_fb_probe

Not called by anyone, and really, shouldn't be. Drivers are supposed either drm_fb_helper_initial_config or drm_fb_helper_hotplug_event. Originally this was done differently, but is now consolidated in the helper functions and no longer done by drivers directly. Signed-off-by: Daniel Vetter ---

[PATCH 06/16] drm/fb-helper: inline drm_fb_helper_single_add_all_connectors

All drivers call this right after drm_fb_helper_init, and the only thing this function does is allocate a bit of memory and set up a bunch of pointers. No reason at all the keep this as a separate step. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/ast/ast_fb.c |1 -

[PATCH 05/16] drm/fb-helper: unexport drm_fb_helper_panic

It doesn't even show up in any header files and only used iternally. Originally it was (ab)used to restore the fbcon on lastclose, but that died with commit e8e7a2b8ccfdae0d4cb6bd25824bbedcd42da316 Author: Dave Airlie Date: Thu Apr 21 22:18:32 2011 +0100 drm/i915: restore only the mode of

[PATCH 04/16] drm/fb-helper: kill drm_fb_helper_restore

It's only used internally for the sysrq and panic handlers provided by the drm fb helper implementation. Hence just inline it, kill the export and remove the confusing kerneldoc. Driver's are supposed to call drm_fb_helper_restore_fbdev_mode on lastclose. Note that locking is totally fubar - the

[PATCH 03/16] drm: review locking for drm_fb_helper_restore_fbdev_mode

... it's required. Fix up exynos and the cma helper, and add a corresponding WARN_ON to drm_fb_helper_restore_fbdev_mode. Note that tegra calls the fbdev cma helper restore function also from it's driver-load callback. Which is a bit against current practice, since usually the call is only from

[PATCH 02/16] omapdrm: simply locking in the fb debugfs file

We don't need to hold onto mode_config.mutex any more to keep the fb objects around. And locking dev->struct_mutex is also not required, since omap_gem_describe only reads data anyway. And for a debug interface it's better to grab fewer locks in case the driver is deadlocked already ... The only

[PATCH 01/16] omapdrm: only take crtc->mutex in crtc callbacks

Omapdrm doesn't do anything nefarious with crtc load detection or has any shared resources, so this is enough. We also need to adjust the WARN_ON. Signed-off-by: Daniel Vetter --- drivers/staging/omapdrm/omap_crtc.c | 12 +--- 1 file changed, 5 insertions(+), 7 deletions(-) diff

[PATCH 00/16] [RFC] drm fb helper cleanups

Hi all, This series is mostly just a bit of fallout from my modeset locking rework which just landed, and some other things I've noticed while rearchitecting the modeset infrastructure for i915.k in 3.7. First two patches are for omapdrm, but included here since they depend upon the locking

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

he other 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/20130124/7b6f6ebb/attachment.html>

[git pull] fbcon locking fixes.

On Thu, Jan 24, 2013 at 4:42 PM, Dave Airlie wrote: > > These patches have been sailing around long enough, waiting for a maintainer > to reappear, so I've decided enough is enough, lockdep is kinda useful to > have. Last this was tried, these patches failed miserably. They caused instant

[git pull] fbcon locking fixes.

On Fri, 25 Jan 2013 00:42:37 + (GMT) Dave Airlie wrote: > These patches have been sailing around long enough, waiting for a maintainer > to reappear, so I've decided enough is enough, lockdep is kinda useful to > have. > > Thanks to Daniel for annoying me enough :-) Me too, but the

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130124/2abc8ac6/attachment.html>

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130124/0f0893bc/attachment-0001.html>

[PATCH V3] drm_crtc: check if fb_create return NULL

On Thu, 2013-01-24 at 10:31 +0200, Jani Nikula wrote: > > } > > + /* some buggy driver may return NULL here, which may cause panic */ > > + BUG_ON(!fb); > > I fail to see the benefit of this compared to just letting it oops... > > > or->fb_id = fb->base.id; > > ...right here. > >

[PATCH] drm/i2c: Add driver for PTN3460 LVDS/DP bridge

On Thu, Jan 24, 2013 at 4:22 PM, Daniel Vetter wrote: > On Thu, Jan 24, 2013 at 7:09 PM, Sean Paul wrote: >> This patch adds the driver for the PTN3460 LVDS/DP bridge chip. >> >> The driver allows the EDID emulation to be selected from device tree, >> along with specifying the GPIOs driving

[PATCH] fbcon: don't lose the console font across generic->chip driver switch

From: Dave Airlie If grub2 loads efifb/vesafb, then when systemd starts it can set the console font on that framebuffer device, however when we then load the native KMS driver, the first thing it does is tear down the generic framebuffer driver. The thing is the generic code

[Bug 59672] Problems initializing Radeon driver: lockup during IB test

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130124/1091c663/attachment.html>

[PATCH 4/4] drm/nouveau: use i2c encoder helper wrappers

On Tue, Jan 08, 2013 at 10:08:46PM -0600, Rob Clark wrote: > Signed-off-by: Rob Clark Yeah, this looks a lot better, and even fixes a small leak on module unload since the allocated func-table isn't freed apparently. Reviewed-by: Daniel Vetter -- Daniel Vetter Software Engineer, Intel

[PATCH] drm/i2c: give i2c it's own Kconfig

Move this out of nouveau directory. As we start to add more encoder slaves used by other drivers, it makes sense to put the Kconfig bits in one place. Signed-off-by: Rob Clark --- drivers/gpu/drm/Kconfig | 2 ++ drivers/gpu/drm/i2c/Kconfig | 22 ++

[PATCH 3/4] drm: i2c encoder helper wrappers

On Tue, Jan 08, 2013 at 10:08:45PM -0600, Rob Clark wrote: > Simplify life for drivers using an encoder-slave, so that they can make > their drm_encoder_helper_funcs const, rather than needing to dynamically > allocate and populate them. > > Signed-off-by: Rob Clark Ah, here they are - looked

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130124/59ddcb01/attachment.html>

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

shifted display. 32bit kernel with patch without option gfxpayload=keep no console display. -- 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/attachm

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

hives/dri-devel/attachments/20130124/b58f132a/attachment.html>

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

atch with the gfxpayload=keep option i atleast get a console but shifted. -- 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/20130124/eda48352/attachment.html>

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

sole. Does removing that option fix the shifted display? -- 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/20130124/51637f42/attachment.html>

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

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

[PATCH] vgacon/vt: clear buffer attributes when we load a 512 character font

From: Dave Airlie When we switch from 256->512 byte font rendering mode, it means the current contents of the screen is being reinterpreted. The bit that holds the high bit of the 9-bit font, may have been previously set, and thus the new font misrenders. The problem case we

[Bug 54133] [radeon][RV620] Resuming from suspend/hibernation randomly fails since kernel 3.5.0

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/20130124/d4d16af9/attachment.html>

[PATCH 4/4] drm/tilcdc: add support for LCD panels (v4)

On Tue, Jan 22, 2013 at 04:36:25PM -0600, Rob Clark wrote: > Add an output panel driver for LCD panels. Tested with LCD3 cape on > beaglebone. > > v1: original > v2: s/of_find_node_by_name()/of_get_child_by_name()/ from Pantelis > Antoniou > v3: add backlight support > v4: rebase to latest

[PATCH 3/4] drm/tilcdc: add encoder slave

On Tue, Jan 22, 2013 at 04:36:24PM -0600, Rob Clark wrote: > Add output panel driver for i2c encoder slaves. > > Signed-off-by: Rob Clark Found some more stuff ... [cut] > +static const struct drm_encoder_helper_funcs slave_encoder_helper_funcs = { > + .dpms =

[PATCH v2] drm/radeon: Enable DMA_IB_SWAP_ENABLE on big endian hosts.

On Thu, Jan 24, 2013 at 1:02 PM, Michel D?nzer wrote: > From: Michel D?nzer > > Fixes GPU hang during DMA ring IB test. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59672 > > Signed-off-by: Michel D?nzer > --- > > v2: The patch fixes real GPU hangs, not just spurious ones. Change

stable backport request

On Thu, Jan 24, 2013 at 10:16:35AM -0800, Greg KH wrote: > On Thu, Jan 24, 2013 at 10:58:25AM +0100, Daniel Vetter wrote: > > Dear stable team > > > > Please backport the following patch to all stable kernels: > > > > 4283908ef7f11a72c3b80dd4cf026f1a86429f82 drm/i915: Implement > >

[PATCH 3/4] drm/tilcdc: add encoder slave

On Tue, Jan 22, 2013 at 04:36:24PM -0600, Rob Clark wrote: > Add output panel driver for i2c encoder slaves. > > Signed-off-by: Rob Clark A few questions below, otherwise Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/tilcdc/Kconfig| 12 ++ > drivers/gpu/drm/tilcdc/Makefile

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130124/47f74ef1/attachment.html>

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

|| -- 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/20130124/0fd9c8f8/attachment.html>

mesa/gles3: dri_util.c:192:10: error: use of undeclared identifier '__DRI_API_GLES3'

Hmm, switching to Ubuntu's distro-kernel, removing /opt/xorg and building the XORG stuff from scratch... 1. libdrm-git 2. mesa-git 3. xf86-video-intel-git ...makes the errors go away. OK, I had in my 3.8-rc4 kernel drm-intel-nightly integrated, but no linux-headers package of this kernel

[PATCH] drm/i2c: Add driver for PTN3460 LVDS/DP bridge

This patch adds the driver for the PTN3460 LVDS/DP bridge chip. The driver allows the EDID emulation to be selected from device tree, along with specifying the GPIOs driving powerdown and reset pins. The chip has a bug in it such that when the powerdown and reset pins are toggled, the hotplug

[PATCH 00/16] [RFC] drm fb helper cleanups

On Thu, Jan 24, 2013 at 10:53:25AM -0600, Rob Clark wrote: > On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter > wrote: > > Hi all, > > > > This series is mostly just a bit of fallout from my modeset locking rework > > which > > just landed, and some other things I've noticed while rearchitecting

[PATCH 2/4] drm/i2c: nxp-tda998x (v2)

On Tue, Jan 22, 2013 at 04:36:23PM -0600, Rob Clark wrote: > Driver for the NXP TDA998X i2c hdmi encoder slave. > > v1: original > v2: fix npix/nline programming > > Signed-off-by: Rob Clark Just one bikeshed, otherwise Reviewed-by: Daniel Vetter [cut] > +static void > +reg_set(struct

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130124/5db5e7e1/attachment.html>

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

ext part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130124/db32a897/attachment.html>

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130124/3772495b/attachment.html>

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130124/dd0befc5/attachment.html>

stable backport request

On Thu, Jan 24, 2013 at 01:59:58PM -0500, Abdallah Chatila wrote: > On Thu, Jan 24, 2013 at 10:16:35AM -0800, Greg KH wrote: > > On Thu, Jan 24, 2013 at 10:58:25AM +0100, Daniel Vetter wrote: > > > Dear stable team > > > > > > Please backport the following patch to all stable kernels: > > > > >

mesa/gles3: dri_util.c:192:10: error: use of undeclared identifier '__DRI_API_GLES3'

Hi Ian, due to the changes in... e90c08e dri: Define enum __DRI_API_GLES3 ...I get this breakage with mesa-gles3-git6f3caaf: make[7]: Entering directory `/home/wearefam/src/mesa/mesa-git/src/mesa/drivers/dri/common' CC utils.lo CC dri_util.lo CC

[PATCH V3] drm_crtc: check if fb_create return NULL

On Thu, 24 Jan 2013, "Su, Xuemin" wrote: > On Thu, 2013-01-24 at 10:31 +0200, Jani Nikula wrote: >> >} >> > + /* some buggy driver may return NULL here, which may cause panic */ >> > + BUG_ON(!fb); >> >> I fail to see the benefit of this compared to just letting it oops... >> >> >

stable backport request

Dear stable team Please backport the following patch to all stable kernels: 4283908ef7f11a72c3b80dd4cf026f1a86429f82 drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50545 Tested-by: Wen-chien Jesse Sung Thanks, Daniel -- Daniel

[PATCH 2/2] drm/i915: fixup per-crtc locking in intel_release_load_detect_pipe

On Wed, Jan 23, 2013 at 05:25:09PM +0100, Daniel Vetter wrote: > One of the early return cases missed the mutex unlocking. Hilarity > ensued. > > This regression has been introduced in > > commit 7b24056be6db7ce907baffdd4cf142ab774ea60c > Author: Daniel Vetter > Date: Wed Dec 12 00:35:33 2012

[PATCH 00/16] [RFC] drm fb helper cleanups

On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter wrote: > Hi all, > > This series is mostly just a bit of fallout from my modeset locking rework > which > just landed, and some other things I've noticed while rearchitecting the > modeset > infrastructure for i915.k in 3.7. > > First two patches

[PATCH 02/16] omapdrm: simply locking in the fb debugfs file

On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter wrote: > We don't need to hold onto mode_config.mutex any more to keep the fb > objects around. And locking dev->struct_mutex is also not required, > since omap_gem_describe only reads data anyway. And for a debug > interface it's better to grab

[PATCH 01/16] omapdrm: only take crtc->mutex in crtc callbacks

On Thu, Jan 24, 2013 at 10:20 AM, Daniel Vetter wrote: > Omapdrm doesn't do anything nefarious with crtc load detection or has > any shared resources, so this is enough. We also need to adjust the > WARN_ON. looks good, after I double checked the locking in setplane. In case I didn't send this

[PATCH v16 RESEND 0/7] of: add display helper

Steffen, You can add my tested-by for this series.. :) I have been using them for Exynos: smdk5250 board. On Wed, Jan 23, 2013 at 2:42 PM, Steffen Trumtrar wrote: > On Tue, Jan 22, 2013 at 03:50:48PM -0600, Rob Clark wrote: >> On Mon, Jan 21, 2013 at 5:07 AM, Steffen Trumtrar >> wrote: >> >

[PATCH V3] drm_crtc: check if fb_create return NULL

On Thu, 24 Jan 2013, "Su, Xuemin" wrote: > From: xueminsu > Date: Tue, 22 Jan 2013 22:39:39 +0800 > Subject: [PATCH] drm_crtc: check if fb_create return NULL > > Some buggy driver may still return NULL in fb_create, > which leads to kernel panic. > > Signed-off-by: xueminsu > --- >

[Mesa-dev] mesa/gles3: dri_util.c:192:10: error: use of undeclared identifier '__DRI_API_GLES3'

FYI, The enum is defined in mesa iteself at #MESA_SOURCE/include/GL/internal/dri_interface.h. Your problem was independent of dri2proto, kernel, drm, etc. I expect your build environment was accidentally #including the header located in /usr/include/GL/internal rather than the one in the mesa

stable backport request

On Thu, Jan 24, 2013 at 10:58:25AM +0100, Daniel Vetter wrote: > Dear stable team > > Please backport the following patch to all stable kernels: > > 4283908ef7f11a72c3b80dd4cf026f1a86429f82 drm/i915: Implement > WaDisableHiZPlanesWhenMSAAEnabled > Bugzilla:

[PATCH v16 RESEND 0/7] of: add display helper

>> > Hi! >> > >> > There was still no maintainer, that commented, ack'd, nack'd, apply'd the >> > series. So, this is just a resend. >> > The patches were tested with: >> > >> > - v15 on Tegra by Thierry >> > - sh-mobile-lcdcfb by Laurent >> > - MX53QSB by Marek >> >

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

kernel with the patch to see if that makes any difference. -- 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/20130124/80f1c

[PATCH v16 RESEND 0/7] of: add display helper

On Thu, Jan 24, 2013 at 10:44:50AM +0530, Leela Krishna Amudala wrote: > Steffen, > > You can add my tested-by for this series.. :) > I have been using them for Exynos: smdk5250 board. > Thanks. I'll use that opportunity for a v17 that is rebased onto 3.8-rc4. Regards, Steffen > On Wed, Jan

[PATCH 3/4] drm: i2c encoder helper wrappers

On Thu, Jan 24, 2013 at 8:42 AM, Daniel Vetter wrote: > On Tue, Jan 08, 2013 at 10:08:45PM -0600, Rob Clark wrote: >> Simplify life for drivers using an encoder-slave, so that they can make >> their drm_encoder_helper_funcs const, rather than needing to dynamically >> allocate and populate them.

[PATCH v16 RESEND 0/7] of: add display helper

On Thu, Jan 24, 2013 at 10:15:54AM +1000, Dave Airlie wrote: > >> > Hi! > >> > > >> > There was still no maintainer, that commented, ack'd, nack'd, apply'd the > >> > series. So, this is just a resend. > >> > The patches were tested with: > >> > > >> > - v15 on Tegra by Thierry > >> >

[PATCH v16 RESEND 0/7] of: add display helper

Hi Steffen, On Thu, Jan 24, 2013 at 13:49:58, Steffen Trumtrar wrote: > Thanks. I'll use that opportunity for a v17 that is rebased onto 3.8-rc4. As you are going to have a v17, if you can fold the diff[1] (that I mentioned earlier) into the patch, "fbmon: add of_videomode helpers", it would be

[PATCH 4/4] drm/tilcdc: add support for LCD panels (v4)

On Thu, Jan 24, 2013 at 7:08 AM, Daniel Vetter wrote: > On Tue, Jan 22, 2013 at 04:36:25PM -0600, Rob Clark wrote: >> Add an output panel driver for LCD panels. Tested with LCD3 cape on >> beaglebone. >> >> v1: original >> v2: s/of_find_node_by_name()/of_get_child_by_name()/ from Pantelis >>

[PATCH V3] drm_crtc: check if fb_create return NULL

From: xueminsu Date: Tue, 22 Jan 2013 22:39:39 +0800 Subject: [PATCH] drm_crtc: check if fb_create return NULL Some buggy driver may still return NULL in fb_create, which leads to kernel panic. Signed-off-by: xueminsu --- drivers/gpu/drm/drm_crtc.c |2 ++ 1 files

[PATCH 3/4] drm/tilcdc: add encoder slave

On Thu, Jan 24, 2013 at 7:01 AM, Daniel Vetter wrote: > On Tue, Jan 22, 2013 at 04:36:24PM -0600, Rob Clark wrote: >> Add output panel driver for i2c encoder slaves. >> >> Signed-off-by: Rob Clark > > Found some more stuff ... > > [cut] > >> +static const struct drm_encoder_helper_funcs

[PATCH 3/4] drm/tilcdc: add encoder slave

On Thu, Jan 24, 2013 at 6:43 AM, Daniel Vetter wrote: > On Tue, Jan 22, 2013 at 04:36:24PM -0600, Rob Clark wrote: >> Add output panel driver for i2c encoder slaves. >> >> Signed-off-by: Rob Clark > > A few questions below, otherwise > > Reviewed-by: Daniel Vetter >> --- [snip] >> diff --git

[PATCH] drm/exynos: add check for the device power status

vel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel > Regards, Shirish S -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130124/e540e529/attachment.html>

[PATCH 2/4] drm/i2c: nxp-tda998x (v2)

On Thu, Jan 24, 2013 at 5:57 AM, Daniel Vetter wrote: > On Tue, Jan 22, 2013 at 04:36:23PM -0600, Rob Clark wrote: >> Driver for the NXP TDA998X i2c hdmi encoder slave. >> >> v1: original >> v2: fix npix/nline programming >> >> Signed-off-by: Rob Clark > > Just one bikeshed, otherwise > >

[PATCH] vgacon/vt: clear buffer attributes when we load a 512 character font

The characters will morph anyway, it is just a matter off having them randomly scream with the intensity bit. 512-character mode is definitely useful... we get much wider language coverage with 512 than with 256, which is why most distros use a 512 console font. Dave Airlie wrote: >On Thu,

[PATCH V2 RESEND] drm_crtc: check if fb_create return NULL

-Original Message- >From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel >Vetter >Sent: Wednesday, January 23, 2013 5:54 PM >To: Su, Xuemin >Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org; linux-kernel at >vger.kernel.org; yanmin_zhang at

Re: [PATCH v16 RESEND 0/7] of: add display helper

On Thu, Jan 24, 2013 at 10:44:50AM +0530, Leela Krishna Amudala wrote: Steffen, You can add my tested-by for this series.. :) I have been using them for Exynos: smdk5250 board. Thanks. I'll use that opportunity for a v17 that is rebased onto 3.8-rc4. Regards, Steffen On Wed, Jan 23,

Re: [PATCH] vgacon/vt: clear buffer attributes when we load a 512 character font

On Thu, Jan 24, 2013 at 3:20 PM, H. Peter Anvin h...@zytor.com wrote: We should clear this bit presumably on switching either from or to 512-char mode, since the bit doesn't really make sense either way. Yeah the only problem going from 512-char is that chars above 256 will morph into garbage

Re: [PATCH V3] drm_crtc: check if fb_create return NULL

On Thu, 24 Jan 2013, Su, Xuemin xuemin...@intel.com wrote: On Thu, 2013-01-24 at 10:31 +0200, Jani Nikula wrote: } + /* some buggy driver may return NULL here, which may cause panic */ + BUG_ON(!fb); I fail to see the benefit of this compared to just letting it oops...

Re: [PATCH 2/2] drm/i915: fixup per-crtc locking in intel_release_load_detect_pipe

On Wed, Jan 23, 2013 at 05:25:09PM +0100, Daniel Vetter wrote: One of the early return cases missed the mutex unlocking. Hilarity ensued. This regression has been introduced in commit 7b24056be6db7ce907baffdd4cf142ab774ea60c Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Wed Dec 12

[Bug 59431] [snb efi gmux] imac 12,1 blank screen upon booting

https://bugs.freedesktop.org/show_bug.cgi?id=59431 --- Comment #25 from William k...@cobradevil.org --- I only use the stock ubuntu kernel. First results: i have built the amd64 with the patch and the system boots with framebuffer console without kernel options. I even can start X :) I'm now

stable backport request

Dear stable team Please backport the following patch to all stable kernels: 4283908ef7f11a72c3b80dd4cf026f1a86429f82 drm/i915: Implement WaDisableHiZPlanesWhenMSAAEnabled Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50545 Tested-by: Wen-chien Jesse Sung je...@cola.voip.idv.tw Thanks,

  1   2   >