Can I put a V4L2 soc camera driver under other subsystem directory?

Hi Bryan, On Wed, 7 Aug 2013, Bryan Wu wrote: > Hi Guennadi and LMML, > > I'm working on a camera controller driver for Tegra, which is using > soc_camera. But we also need to use Tegra specific host1x interface > like syncpt APIs. > > Since host1x is quite Tegra specific framework which is in

[Bug 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU

L: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/2e45e4b0/attachment.html>

[Bug 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU

low. -- 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/20130808/8484eb91/attachment.html>

[Bug 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU

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

[PATCH v2] drm: provide agp dummies for CONFIG_AGP=n

We currently rely on gcc dead-code elimination so the drm_agp_* helpers are not called if drm_core_has_AGP() is false. That's ugly as hell so provide "static inline" dummies for the case that AGP is disabled. Fixes a build-regression introduced by: commit

Build break due to 28ec711 "drm/agp: move AGP cleanup paths to drm_agpsupport.c"

Hi On Thu, Aug 8, 2013 at 9:21 PM, Stephen Warren wrote: > On 08/08/2013 12:13 PM, David Herrmann wrote: >> Hi >> >> On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren >> wrote: >>> In next-20130808, building tegra_defconfig for ARM yields: >>> >&g

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

not dpm related. -- 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/20130808/6e7e9467/attachment.html>

[PATCH] drm: Add drm_bridge

On Thu, Aug 8, 2013 at 8:36 PM, Daniel Vetter wrote: > On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul wrote: >> This patch adds the notion of a drm_bridge. A bridge is a chained >> device which hangs off an encoder. The drm driver using the bridge >> should provide the association between encoder

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

org/archives/dri-devel/attachments/20130808/a9febd0b/attachment.html>

drm/agp linux-next build broken for non-AGP platform

Hi On Thu, Aug 8, 2013 at 12:01 PM, Vincent Stehl? wrote: > Hi, > > Linux next-20130808 link breaks for me with ARM config multi_v7defconfig. > > It seems this is due to the following commit: > > 28ec711 drm/agp: move AGP cleanup paths to drm_agpsupport.c > > .

[PATCH] drm/agp: Fix build for non-AGP platforms

Hi On Thu, Aug 8, 2013 at 12:20 PM, Mark Brown wrote: > From: Mark Brown > > Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c) > broke the build for platforms which do not have AGP since it moved the > AGP cleanup code inside an #ifdef __OS_HAS_AGP which are referenced >

Build break due to 28ec711 "drm/agp: move AGP cleanup paths to drm_agpsupport.c"

Hi On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren wrote: > In next-20130808, building tegra_defconfig for ARM yields: > >> drivers/built-in.o: In function `drm_lastclose': >> /home/swarren/shared/git_wa/kernel/kernel.git/drivers/gpu/drm/drm_drv.c:198: >> undefined ref

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

ttachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/4d7c5e11/attachment.html>

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

separately. -- 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/20130808/d6955347/attachment.html>

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

ent was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/ccd32288/attachment.html>

[PATCH] drm: fix minor number range calculation

Hi On Thu, Aug 8, 2013 at 7:10 PM, David Herrmann wrote: > Currently, both ranges overlap. Fix the limits so both ranges are mutually > exclusive. Also use the occasion to convert whitespaces to tabs. > > Signed-off-by: Kristian H?gsberg > (fixed up tabs and adjust commit-msg accordingly) >

[PATCH] drm: fix minor number range calculation

Currently, both ranges overlap. Fix the limits so both ranges are mutually exclusive. Also use the occasion to convert whitespaces to tabs. Signed-off-by: Kristian H?gsberg (fixed up tabs and adjust commit-msg accordingly) Signed-off-by: David Herrmann --- drivers/gpu/drm/drm_stub.c | 12

[PATCH] drm: drm_drv: Only call drm_agp_clear() in __OS_HAS_AGP case

From: Fabio Estevam Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c) causes the following link error on ARM (imx_v6_v7_defconfig): drivers/built-in.o: In function `drm_lastclose': :(.text+0x588a0): undefined reference to `drm_agp_clear' make:

[PATCH] drm: Add drm_bridge

On Thu, Aug 8, 2013 at 5:36 PM, Daniel Vetter wrote: > On Thu, Aug 8, 2013 at 11:03 PM, Sean Paul wrote: >> This patch adds the notion of a drm_bridge. A bridge is a chained >> device which hangs off an encoder. The drm driver using the bridge >> should provide the association between encoder

[PATCH 22/25] drm: no-op out GET_STATS ioctl

19, 21, 22, 24, 25 are: Reviewed-by: Eric Anholt -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/5d231387/attachment.pgp>

[PATCH 5/9] drm/gem: add drm_gem_create_mmap_offset_size()

Hi On Wed, Aug 7, 2013 at 7:41 PM, Rob Clark wrote: > Variant of drm_gem_create_mmap_offset() which doesn't make the > assumption that virtual size and physical size (obj->size) are the same. > This is needed in omapdrm to deal with tiled buffers. And lets us get > rid of a duplicated and

[Intel-gfx] 3.10.2 : new warning WARNING: at drivers/gpu/drm/i915/intel_display.c:1656 ironlake_crtc_disable+0x7ce/0x800 [i915]()

On 08/06/2013 08:03 PM, Daniel Vetter wrote: > On Tue, Aug 6, 2013 at 7:42 PM, Toralf F?rster > wrote: >> On 07/26/2013 07:58 PM, Daniel Vetter wrote: >>> On Wed, Jul 24, 2013 at 05:51:41PM +0200, Toralf F?rster wrote: Realized this today while booting a ThinkPad T420 with integrated intel

[PATCH 0/8] Several NXP TDA998x patches

Sebastian Hesselbarth wrote on Tue [2013-Aug-06 00:20:10 +0200]: > This patch set picks up several patches sent during the past months > related with NXP TDA998x HDMI transmitter driver. The patches have > been tested on Marvell Dove (Armada DRM) on several HDMI modes with > audio playing on

[PATCH] drm: Add drm_bridge

This patch adds the notion of a drm_bridge. A bridge is a chained device which hangs off an encoder. The drm driver using the bridge should provide the association between encoder and bridge. Once a bridge is associated with an encoder, it will participate in mode set, dpms, and optionally

[PATCH 25/25] drm: move dev data clearing from drm_setup to lastclose

We kzalloc this structure, and for real kms devices we should never loose track of things really. But ums/legacy drivers rely on the drm core to clean up a bit of cruft between lastclose and firstopen (i.e. when X is being restarted), so keep this around. But give it a clear drm_legacy_ prefix

[PATCH 24/25] drm: remove procfs code, take 2

So almost two years ago I've tried to nuke the procfs code already once before: http://lists.freedesktop.org/archives/dri-devel/2011-October/015707.html The conclusion was that userspace drivers (specifically libdrm device node detection) stopped relying on procfs in 2001. But after some digging

[PATCH 23/25] drm: fix locking in gem debugfs/procfs file

The idr is protected with our spinlock, if we don't hold that nothing prevents the gem objects from disappearing from under us. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_info.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/drm_info.c

[PATCH 22/25] drm: no-op out GET_STATS ioctl

Again only used by a tests in libdrm and by dristat. Nowadays we have much better tracing tools to get detailed insights into what a drm driver is doing. And for a simple "does it work" kind of question that these stats could answer we have plenty of dmesg debug log spew. So I don't see any use

[PATCH 21/25] drm: hollow-out GET_CLIENT ioctl

We not only have debugfs files to do pretty much the equivalent of lsof, we also have an ioctl. Not that compared to lsof this dumps a wee bit more information, but we can still get at that from debugfs easily. I've dug around in mesa, libdrm and ddx histories and the only users seem to be

[PATCH 20/25] drm/memory: don't export agp helpers

They're only used by the agpgart support code in drm_agpgart.c, not by any drivers. I think long-term we should create a drm_internal.h include file with all the various functions only used by the drm core and not exported to drivers, and remove them from drmP.h. Oh, and someone should kill that

[PATCH 19/25] drm: remove the dma_ioctl special-case

We might as well have a real ioctl function which checks for the callbacks. This seems to be a remnant from back in the days when each drm driver had their own complete ioctl table, with no shared core drm table at all. To make really sure no mis-guided user in a kms driver pops up again

[PATCH 18/25] drm/docs: rip out removed driver flags documentation

I've forgotten this and shuffling all the little pieces into the respective patches is rather cumbersome ... Signed-off-by: Daniel Vetter --- Documentation/DocBook/drm.tmpl | 29 - 1 file changed, 29 deletions(-) diff --git a/Documentation/DocBook/drm.tmpl

[PATCH 17/25] drm: rip out drm_core_has_MTRR checks

The new arch_phys_wc_add/del functions do the right thing both with and without MTRR support in the kernel. So we can drop these additional checks. David Herrmann suggest to also kill the DRIVER_USE_MTRR flag since it's now unused, which spurred me to do a bit a better audit of the affected

[PATCH 16/25] drm: remove a bunch of unused #defines from drmP.h

Signed-off-by: Daniel Vetter --- include/drm/drmP.h | 9 - 1 file changed, 9 deletions(-) diff --git a/include/drm/drmP.h b/include/drm/drmP.h index f526a7a9..914055e 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@ -165,13 +165,7 @@ int drm_err(const char *func, const char

[PATCH 15/25] drm: rip out a few unused DRIVER flags

The gma500 driver somehow set the DRIVER_IRQ_VBL flag, but since there's no code at all to check for this we can kill it. The other two are completely unused. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/gma500/psb_drv.c | 2 +- include/drm/drmP.h | 3 --- 2 files changed, 1

[PATCH 14/25] drm: rip out DRIVER_FB_DMA and related code

No driver ever sets that flag, so good riddance! Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_bufs.c | 161 + include/drm/drmP.h | 1 - 2 files changed, 2 insertions(+), 160 deletions(-) diff --git a/drivers/gpu/drm/drm_bufs.c

[PATCH 13/25] drm: remove FASYNC support

So I've stumbled over drm_fasync and wondered what it does. Digging that up is quite a story. First I've had to read up on what this does and ended up being rather bewildered why peopled loved signals so much back in the days that they've created SIGIO just for that ... Then I wondered how this

[PATCH 12/25] drm/vmwgfx: remove redundant clearing of driver->dma_quiescent

It's kzalloced ... Signed-off-by: Daniel Vetter --- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c index cebd847..9c27d42 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c +++

[PATCH 11/25] drm: mark context support as a legacy subsystem

So after a lot of digging around in git histories it looks like this has only ever be used by dri1 render clients. Hence we can fully disable the entire thing for modesetting drivers and so greatly reduce the attack surface for potential exploits (or at least tools like trinity ...). Also add the

[PATCH 10/25] drm: disallow legacy dma ioctls for modesetting drivers

Now only legacy ums drivers have the DRIVER_HAVE_DMA driver feature flag set, so strictly speaking the modesetting check is redundant. But adding it has the upside that it makes it very clear that the dma support is legacy stuff. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_bufs.c | 15

[PATCH 09/25] drm: mark dma setup/teardown as legacy systems

And hide the checks a bit better. This was already disallowed for modesetting drivers, so no functinal change here. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_dma.c | 17 +++-- drivers/gpu/drm/drm_drv.c | 4 +--- drivers/gpu/drm/drm_fops.c | 12 +++-

[PATCH 08/25] drm: disallow legacy sg ioctls for modesetting drivers

Only the radeon/r128/ati ums drivers use this. Furthermore the cleanup was already only done for UMS drivers. Also a quick check of the ATI ddx git history shows that only the UMS code ever used this facility. So we can safely disallow these pair of ioctls for modesetting drivers. Signed-off-by:

[PATCH 07/25] drm: hide legacy sg cleanup better from common code

I've decided that some clear markers for what's legacy dri1/non-gem code is useful. I've opted to use the drm_legacy prefix and then hide all the checks in that function for better readability in the common code. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_drv.c | 6 +-

[PATCH 06/25] drm: kill dev->driver->set_version

Totally unused, so just rip it out. Anyway, we want drivers to be fully backwards compatible, allowing them to change behaviour is just a recipe for them to break badly. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_ioctl.c | 3 --- include/drm/drmP.h | 2 -- 2 files changed, 5

[PATCH 05/25] drm: don't call ->firstopen for KMS drivers

It has way too much potential for driver writers to do stupid things like delayed hw setup because the load sequence is somehow racy (e.g. the imx driver in staging). So don't call it for modesetting drivers, which reduces the complexity of the drm core -> driver interface a notch. v2: Don't

[PATCH 04/25] drm/vmwgfx: remove ->firstopen callback

So if we survey kms drivers there's a bunch of things they commonly do in ->lastclose - delayed processing of vga switcheroo requests (i915, nouveau, radeon) - force-restoring the fbcon (most) - resetting a bunch properties to make fbcon work better (omap) - disabling all outputs (vmwgfx) In

[PATCH 03/25] drm/imx: kill firstopen callback

This thing seems to do some kind of delayed setup. Really, real kms drivers shouldn't do that at all. Either stuff needs to be dynamically hotplugged or the driver setup sequence needs to be fixed. This patch here just moves the setup at the very end of the driver load callback, with the locking

[PATCH 02/25] drm/radeon: kill firstopen callback for kms driver

Again, it does nothing. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/radeon/radeon_drv.c | 2 -- drivers/gpu/drm/radeon/radeon_kms.c | 13 - 2 files changed, 15 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index

[PATCH 01/25] drm/omap: kill firstopen callback

KMS drivers really shouldn't need to do anything on firstopen, so kill empty callbacks. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/omapdrm/omap_drv.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c index

[PATCH 00/25] drm cruft removal

Hi all, So a bunch of patches went in already, and a few of the ones here small fixups (DocBook, compile fail for funny .configs and 1 unused variable). And slight rebasing on top of David's drm_dev cleanup refactoring. The big change is that the get_client ioclt isn't a complete noop now but

[3.11-rc4] [HD2400] - radeon.dpm

rm/card0/device/power_dpm_state > >> > balanced > >> > > >> > dmesg: radeon: dpm initialized > >> > > >> > No specific error in dmesg... > >> > > >> > Regards > >> > Sam > >> > > >> > ___ > >> > dri-devel mailing list > >> > dri-devel at lists.freedesktop.org > >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel > >> > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/19251379/attachment-0001.html>

[PATCH v2] drm: provide agp dummies for CONFIG_AGP=n

On 08/08/2013 02:19 PM, David Herrmann wrote: > We currently rely on gcc dead-code elimination so the drm_agp_* helpers > are not called if drm_core_has_AGP() is false. That's ugly as hell so > provide "static inline" dummies for the case that AGP is disabled. > > Fixes a build-regression

Can I put a V4L2 soc camera driver under other subsystem directory?

On Thu, Aug 8, 2013 at 1:52 PM, Guennadi Liakhovetski wrote: > Hi Bryan, > > On Wed, 7 Aug 2013, Bryan Wu wrote: > >> Hi Guennadi and LMML, >> >> I'm working on a camera controller driver for Tegra, which is using >> soc_camera. But we also need to use Tegra specific host1x interface >> like

[PATCH 1/4] drm/exynos: explicit store base gem object in dma_buf->priv

Hi, Daniel. You can repost your patch set including the below my patch. And my patch numbering is wrong. Sorry about that. [PATCH 1/4] -> [PATCH 4/4] Thanks, Inki Dae > -Original Message- > From: Inki Dae [mailto:inki.dae at samsung.com] > Sent: Thursday, August 08, 2013 1:40 PM > To:

[PATCH 1/4] drm/exynos: explicit store base gem object in dma_buf->priv

Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12 1 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c index 3cd56e1..fd76449

[PATCH 1/3] drm: use common drm_gem_dmabuf_release in i915/exynos drivers

> -Original Message- > From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel > Vetter > Sent: Thursday, August 08, 2013 8:21 AM > To: Inki Dae > Cc: Daniel Vetter; Intel Graphics Development; DRI Development > Subject: Re: [PATCH 1/3] drm: use common

[Bug 67888] R600g: GPU hang occurs when trying to do GPU profile of Trine 2 apitrace trace

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130808/637fd49a/attachment.html>

Build break due to 28ec711 "drm/agp: move AGP cleanup paths to drm_agpsupport.c"

On 08/08/2013 12:13 PM, David Herrmann wrote: > Hi > > On Thu, Aug 8, 2013 at 8:00 PM, Stephen Warren > wrote: >> In next-20130808, building tegra_defconfig for ARM yields: >> >>> drivers/built-in.o: In function `drm_lastclose': >>> /home/swarren/share

[Bug 67901] New: Black screen or freeze on radeon driver on AMD 6470M / Intel HD 3000

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/20130808/246ce781/attachment.html>

[Bug 66738] System freeze randomly with latest kernel 3.10 (also 3.11-rc4)

vel/attachments/20130808/625394f3/attachment-0001.html>

[Bug 60720] System freeze randomly with latest kernel 3.10 (also 3.11-rc4)

https://bugzilla.kernel.org/show_bug.cgi?id=60720 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

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

[3.11-rc4] [HD2400] - radeon.dpm

On Thu, Aug 8, 2013 at 11:34 AM, miaou sami wrote: > Hi, > > thanks for the explanation. > Do you know if this is a hardware limitation, or if an updated version of > the driver will come some day? It's not a hardware limitation. The driver relies on what the OEM put in the power tables as that

[Bug 67876] linux v4.11-rc1 many drm:radeon_ttm_backend_bind ERROR failed to bind 2025 pages issued during boot

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

[pull] radeon drm-fixes-3.11

> -Original Message- > From: Rafa? Mi?ecki [mailto:zajec5 at gmail.com] > Sent: Thursday, August 08, 2013 12:37 AM > To: Alex Deucher > Cc: dri-devel at lists.freedesktop.org; airlied at gmail.com; Deucher, > Alexander > Subject: Re: [pull] radeon drm-fixes-3.11 > > 2013/8/8 Alex Deucher

[Bug 60720] New: System freeze randomly with latest kernel 3.10 (also 3.11-rc4)

https://bugzilla.kernel.org/show_bug.cgi?id=60720 Bug ID: 60720 Summary: System freeze randomly with latest kernel 3.10 (also 3.11-rc4) Product: Drivers Version: 2.5 Kernel Version: 3.10 to 3.11-rc4 Hardware: All

Build break due to 28ec711 "drm/agp: move AGP cleanup paths to drm_agpsupport.c"

In next-20130808, building tegra_defconfig for ARM yields: > drivers/built-in.o: In function `drm_lastclose': > /home/swarren/shared/git_wa/kernel/kernel.git/drivers/gpu/drm/drm_drv.c:198: > undefined reference to `drm_agp_clear' That's because drm_agp_clear() is called uncondition

[PATCH] drm/agp: Fix build for non-AGP platforms

From: Mark Brown Commit 28ec711 (drm/agp: move AGP cleanup paths to drm_agpsupport.c) broke the build for platforms which do not have AGP since it moved the AGP cleanup code inside an #ifdef __OS_HAS_AGP which are referenced unconditionally in drm_drv.c. This causes build

[PATCH v3] drm: use ida to allocate connector ids

On Wed, Aug 07, 2013 at 10:34:48PM -0400, Ilia Mirkin wrote: > This makes it so that reloading a module does not cause all the > connector ids to change, which are user-visible and sometimes used > for configuration. > > Signed-off-by: Ilia Mirkin > --- > > v2 -> v3: > - rename ida struct name

[GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC

On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote: > Hi Dave, > > I've got a couple of arch/arm/ patches that depend on this series and that I > would like to get merged in v3.12. They should go upstream through the arm-soc > tree. Would you be able to provide a stable branch with this

[GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC

On Thu, Aug 08, 2013 at 03:34:17AM +0200, Laurent Pinchart wrote: > Hi Dave, > > (CC'ing Simon Horman, the shmobile tree maintainer) > > On Thursday 08 August 2013 10:57:33 Dave Airlie wrote: > > On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote: > > > Hi Dave, > > > > > > I've got a

[Bug 60532] Suspend with dedicated graphics card switched off breaking with kernel version 3.8.0-25+

https://bugzilla.kernel.org/show_bug.cgi?id=60532 Jani Nikula changed: What|Removed |Added Component|Video(DRI - Intel) |Video(DRI - non Intel)

[Bug 60606] vga_switcheroo / new Radeon DPM code mess up fbcon

https://bugzilla.kernel.org/show_bug.cgi?id=60606 --- Comment #4 from Sebastien Fievet --- (In reply to Jani Nikula from comment #3) I reverted the patch and double checked. The workaround is enough for me. What I do is : 1. echo OFF > /sys/kernel/debug/vgaswitcheroo/switch at init time with a

[PATCH 06/25] drm: kill dev->driver->set_version

On Thu, Aug 8, 2013 at 9:41 AM, Daniel Vetter wrote: > Totally unused, so just rip it out. Anyway, we want drivers to be > fully backwards compatible, allowing them to change behaviour is just > a recipe for them to break badly. > > Signed-off-by: Daniel Vetter Reviewed-by: Rob Clark > --- >

[PATCH 01/25] drm/omap: kill firstopen callback

On Thu, Aug 8, 2013 at 9:41 AM, Daniel Vetter wrote: > KMS drivers really shouldn't need to do anything on firstopen, so kill > empty callbacks. > > Signed-off-by: Daniel Vetter Acked-by: Rob Clark > --- > drivers/gpu/drm/omapdrm/omap_drv.c | 7 --- > 1 file changed, 7 deletions(-) > >

[PULL] drm-intel-fixes

Hi Dave, A few bugfixes for serious stuff and regressions. Highlight is the reinstated hack to keep the i915 backlight on when running on an optimus machine, this prevents black screens especially with some radeon muxed platforms. And the patch to quiet dmesg on Linus' old mac mini ;-) Cheers,

[PATCH 5/5] drm/prime: remove cargo-cult locking from map_sg helper

I've checked both implementations (radeon/nouveau) and they both grab the page array from ttm simply by dereferencing it and then wrapping it up with drm_prime_pages_to_sg in the callback and map it with dma_map_sg (in the helper). Only the grabbing of the underlying page array is anything we

[PATCH 4/5] drm/exynos: explicit store base gem object in dma_buf->priv

From: Inki Dae Signed-off-by: Inki Dae Signed-off-by: Kyungmin Park Signed-off-by: Daniel Vetter --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c

[PATCH 3/5] drm/i915: explicit store base gem object in dma_buf->priv

Makes it more obviously correct what tricks we play by reusing the drm prime release helper. Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 21 - 1 file changed, 12 insertions(+), 9 deletions(-) diff --git

[PATCH 2/5] drm/i915: unpin backing storage in dmabuf_unmap

This fixes a WARN in i915_gem_free_object when the obj->pages_pin_count isn't 0. v2: Add locking to unmap, noticed by Chris Wilson. Note that even though we call unmap with our own dev->struct_mutex held that won't result in an immediate deadlock since we never go through the dma_buf interfaces

[PATCH 1/5] drm: use common drm_gem_dmabuf_release in i915/exynos drivers

Note that this is slightly tricky since both drivers store their native objects in dma_buf->priv. But both also embed the base drm_gem_object at the first position, so the implicit cast is ok. To use the release helper we need to export it, too. Cc: Inki Dae Cc: Intel Graphics Development

[PATCH 0/5] First cut of prime patches for drm-next

Hi Dave, Inki supplied a patch to convert exynos, so I think these prep patches are ready to go in. I want a common drm_gem_dmabuf_release function across all drivers since th oops fix around the teardown of the obj->export_dma_buf pointer needs to have changed code in there, and duplicating

[PATCH 1/4] drm/exynos: explicit store base gem object in dma_buf->priv

Hi Inki, On Thu, Aug 08, 2013 at 01:56:28PM +0900, Inki Dae wrote: > Hi, Daniel. You can repost your patch set including the below my patch. And > my patch numbering is wrong. Sorry about that. Thanks for the patch, I'll submit it toghether with the other ones soon. -Daniel > > [PATCH 1/4] ->

[PATCH 1/3] drm: use common drm_gem_dmabuf_release in i915/exynos drivers

On Thu, Aug 8, 2013 at 6:32 AM, Inki Dae wrote: > > >> -Original Message- >> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel >> Vetter >> Sent: Thursday, August 08, 2013 8:21 AM >> To: Inki Dae >> Cc: Daniel Vetter; Intel Graphics Development; DRI Development >>

[Bug 67800] Computer freezes after idle for several hours (trinity)

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

[Bug 67888] New: R600g: GPU hang occurs when trying to do GPU profile of Trine 2 apitrace trace

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

[Bug 60606] vga_switcheroo / new Radeon DPM code mess up fbcon

https://bugzilla.kernel.org/show_bug.cgi?id=60606 --- Comment #3 from Jani Nikula --- Sebastien, to confirm, you need "drm/i915: do not disable backlight on vgaswitcheroo switch off" to be able to switch from IGD to DIS? So having that is an improvement? And without that, the workarounds won't

[pull] radeon drm-fixes-3.11

2013/8/8 Alex Deucher : > Some more radeon fixes. Mostly dpm and uvd fixes. Fixes hangs > with dpm on more rv6xx asics, and fixes suspend and resume with UVD. That fix audio dto calculation on DCE3+ looks promising, I had no idea you're working on that. Thanks for releasing that! Maybe you

[GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC

Hi Dave, (CC'ing Simon Horman, the shmobile tree maintainer) On Thursday 08 August 2013 10:57:33 Dave Airlie wrote: > On Thu, Aug 8, 2013 at 10:43 AM, Laurent Pinchart wrote: > > Hi Dave, > > > > I've got a couple of arch/arm/ patches that depend on this series and that > > I would like to get

[GIT PULL FOR v3.12] R-Car DU DRM support for R8A7790 SoC

Hi Dave, I've got a couple of arch/arm/ patches that depend on this series and that I would like to get merged in v3.12. They should go upstream through the arm-soc tree. Would you be able to provide a stable branch with this patch set based on one of the 3.11-rcX tags ? Ideally that branch

[PATCH 1/2] drm/i915: unpin backing storage in dmabuf_unmap

On Wed, Aug 07, 2013 at 08:50:20PM -0400, Konrad Rzeszutek Wilk wrote: > On Wed, Aug 07, 2013 at 12:09:32PM +0200, Daniel Vetter wrote: > > This fixes a WARN in i915_gem_free_object when the > > obj->pages_pin_count isn't 0. > > > > v2: Add locking to unmap, noticed by Chris Wilson. Note that

[PATCH 1/3] drm: use common drm_gem_dmabuf_release in i915/exynos drivers

On Wed, Aug 07, 2013 at 09:37:52PM +0900, Inki Dae wrote: > 2013/8/7 Daniel Vetter > > > On Wed, Aug 7, 2013 at 2:01 PM, Inki Dae wrote: > > > > > > > > > 2013/8/7 Daniel Vetter > > >> > > >> On Wed, Aug 07, 2013 at 07:18:45PM +0900, Joonyoung Shim wrote: > > >> > On 08/07/2013 06:55 PM,

[Bug 67876] linux v4.11-rc1 many drm:radeon_ttm_backend_bind ERROR failed to bind 2025 pages issued during boot

l/attachments/20130808/91d8796e/attachment.html>

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/0c7dd62c/attachment.html>

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

th dpm disabled? -- 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/20130808/7fe95399/attachment.html>

[Bug 66963] r600: linux 3.11RC isn't booting with radeon.dpm=1 option in grub

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130808/091381d5/attachment.html>

Re: [PATCH 1/3] drm: use common drm_gem_dmabuf_release in i915/exynos drivers

On Thu, Aug 8, 2013 at 6:32 AM, Inki Dae inki@samsung.com wrote: -Original Message- From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter Sent: Thursday, August 08, 2013 8:21 AM To: Inki Dae Cc: Daniel Vetter; Intel Graphics Development; DRI Development

Re: [PATCH 1/4] drm/exynos: explicit store base gem object in dma_buf-priv

Hi Inki, On Thu, Aug 08, 2013 at 01:56:28PM +0900, Inki Dae wrote: Hi, Daniel. You can repost your patch set including the below my patch. And my patch numbering is wrong. Sorry about that. Thanks for the patch, I'll submit it toghether with the other ones soon. -Daniel [PATCH 1/4] -

[Bug 60606] vga_switcheroo / new Radeon DPM code mess up fbcon

https://bugzilla.kernel.org/show_bug.cgi?id=60606 --- Comment #3 from Jani Nikula jani.nik...@intel.com --- Sebastien, to confirm, you need drm/i915: do not disable backlight on vgaswitcheroo switch off to be able to switch from IGD to DIS? So having that is an improvement? And without that, the

[PATCH 0/5] First cut of prime patches for drm-next

Hi Dave, Inki supplied a patch to convert exynos, so I think these prep patches are ready to go in. I want a common drm_gem_dmabuf_release function across all drivers since th oops fix around the teardown of the obj-export_dma_buf pointer needs to have changed code in there, and duplicating

  1   2   >