Best practice device tree design for display subsystems/DRM

On Tue, Jul 2, 2013 at 9:46 PM, St?phane Marchesin wrote: > On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie wrote: >> On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer >> wrote: >>> On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote: On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian

[PATCH] drm/radeon/dpm: Add #include to *_dpm.c files

my GCC 4.8.1 system using ld.gold - I'm > not sure why > > Cheers > > Mike > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130702/77461d2d/attachment.html> -- next part

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600

Alex Deucher wrote, on 07/02/2013 22:17: > On Tue, Jul 2, 2013 at 4:15 PM, J?rg-Volker Peetz wrote: >> Alex Deucher wrote, on 07/02/2013 21:46: >>> On Tue, Jul 2, 2013 at 10:09 AM, J?rg-Volker Peetz >>> wrote: With self-compiled linux 3.10 on a HP Pavilion dv7 with hybrid graphics

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600

Alex Deucher wrote, on 07/02/2013 21:46: > On Tue, Jul 2, 2013 at 10:09 AM, J?rg-Volker Peetz wrote: >> With self-compiled linux 3.10 on a HP Pavilion dv7 with hybrid graphics (ATI >> RS880M [Mobility Radeon HD 4200 Series] / ATI Manhattan [Mobility Radeon HD >> 5400 >> Series]) uvd seems to be

Best practice device tree design for display subsystems/DRM

On 07/02/2013 09:19 PM, Russell King wrote: > On Tue, Jul 02, 2013 at 08:42:55PM +0200, Jean-Francois Moine wrote: >> It seems that you did not look at the NVIDIA Tegra driver (I got its >> general concept for my own driver, but I used a simple atomic counter): >> >> - at probe time, the main

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On Tue, Jul 02, 2013 at 07:23:27PM +0100, Russell King - ARM Linux wrote: > On Tue, Jul 02, 2013 at 09:01:55PM +0300, Ville Syrj?l? wrote: > > On Sun, Jun 30, 2013 at 07:29:27PM +0200, Daniel Vetter wrote: > > > On Sun, Jun 30, 2013 at 2:52 PM, Russell King - ARM Linux > > > wrote: > > > > |

[PATCH] drm/exynos: fix pages allocation in lowlevel_buffer_allocate

2013/7/2 YoungJun Cho : > Dear Ville > > On Jul 2, 2013 8:42 PM, "Ville Syrj?l?" > wrote: >> >> On Tue, Jul 02, 2013 at 07:59:22PM +0900, Seung-Woo Kim wrote: >> > From: YoungJun Cho >> > >> > When drm iommu is not supported, buf->pages has to be allocated >> > and assigned to phys_to_page()

Best practice device tree design for display subsystems/DRM

On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote: > I am against a super node which contains lcd and dcon/ire nodes. You can > enable those devices on a per board basis. We add them to dove.dtsi but > disable them by default (status = "disabled"). > > The DRM driver itself

[PATCH] drm/exynos: fix pages allocation in lowlevel_buffer_allocate

vel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > > -- > Ville Syrj?l? > Intel OTC > ___ > 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/20130702/4036e6f5/attachment.html>

[PATCH] drm/exynos: Add missing includes

> -Original Message- > From: Mark Brown [mailto:broonie at kernel.org] > Sent: Monday, July 01, 2013 9:56 PM > To: Inki Dae; Joonyoung Shim; Seung-Woo Kim; Kyungmin Park; David Airlie > Cc: dri-devel at lists.freedesktop.org; linux-arm-kernel at > lists.infradead.org; >

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On Sun, Jun 30, 2013 at 07:29:27PM +0200, Daniel Vetter wrote: > On Sun, Jun 30, 2013 at 2:52 PM, Russell King - ARM Linux > wrote: > > On Sun, Jun 30, 2013 at 01:59:41PM +0200, Daniel Vetter wrote: > >> On Sat, Jun 29, 2013 at 11:53:22PM +0100, Russell King wrote: > >> > +static uint32_t

Best practice device tree design for display subsystems/DRM

On Tue, 2 Jul 2013 11:43:59 -0600 Daniel Drake wrote: > Hi, Hi Daniel, > I'm looking into implementing devicetree support in armada_drm and > would like to better understand the best practice here. > > Adding DT support for a DRM driver seems to be complicated by the fact > that DRM is not

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

080528 for :05:00.0 on minor 0 Justin. -- 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/20130702/9b9bfa5d/attachment.html>

Best practice device tree design for display subsystems/DRM

On Tue, Jul 02, 2013 at 08:42:55PM +0200, Jean-Francois Moine wrote: > It seems that you did not look at the NVIDIA Tegra driver (I got its > general concept for my own driver, but I used a simple atomic counter): > > - at probe time, the main driver (drivers/gpu/host1x/drm/drm.c) scans > the

Best practice device tree design for display subsystems/DRM

On Tue, Jul 02, 2013 at 12:54:41PM -0600, Daniel Drake wrote: > On Tue, Jul 2, 2013 at 12:43 PM, Russell King wrote: > > I will point out that relying on driver probing orders has already been > > stated by driver model people to be unsafe. This is why I will not > > adopt such a solution for my

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

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

[PATCH] drm/exynos: fix pages allocation in lowlevel_buffer_allocate

From: YoungJun Cho When drm iommu is not supported, buf->pages has to be allocated and assigned to phys_to_page() result, which type is struct page *. So it is sufficient to allocate buf->pages with multiple struct page pointer size. Signed-off-by: YoungJun Cho

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

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

[Bug 66519] 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

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

[Bug 66519] New: 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

hments/20130702/5ec7d74d/attachment.html>

Best practice device tree design for display subsystems/DRM

On Tue, Jul 02, 2013 at 11:43:59AM -0600, Daniel Drake wrote: > exynos seems to take a the same approach. Components are separate in > the device tree, and each component is implemented as a platform > driver or i2c driver. However all the drivers are built together in > the same module, and the

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On Tue, Jul 02, 2013 at 09:01:55PM +0300, Ville Syrj?l? wrote: > On Sun, Jun 30, 2013 at 07:29:27PM +0200, Daniel Vetter wrote: > > On Sun, Jun 30, 2013 at 2:52 PM, Russell King - ARM Linux > > wrote: > > > | Default Colorimetry > > > | > > > | ... > > > | > > > | 480p, 480i, 576p, 576i, 240p and

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600

On Tue, Jul 2, 2013 at 4:34 PM, J?rg-Volker Peetz wrote: > Alex Deucher wrote, on 07/02/2013 22:17: >> On Tue, Jul 2, 2013 at 4:15 PM, J?rg-Volker Peetz wrote: >>> Alex Deucher wrote, on 07/02/2013 21:46: On Tue, Jul 2, 2013 at 10:09 AM, J?rg-Volker Peetz wrote: > With

Best practice device tree design for display subsystems/DRM

On Tue, Jul 2, 2013 at 3:02 PM, Dave Airlie wrote: > On Wed, Jul 3, 2013 at 7:50 AM, Sascha Hauer > wrote: >> On Tue, Jul 02, 2013 at 09:25:48PM +0100, Russell King wrote: >>> On Tue, Jul 02, 2013 at 09:57:32PM +0200, Sebastian Hesselbarth wrote: >>> > I am against a super node which contains

[ANNOUNCE] libdrm 2.4.46

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Release because I want the cursor ioctls released, also haswell and radeon ids. Alex Deucher (3): radeon: add CIK chip families radeon: add Bonaire pci ids radeon: add kabini pci ids Damien Lespiau (3): intel/aub: Sync the

[PATCH v3 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

If raw_edid of drm_edid_block_vaild() is null, it will crash, so checking in bad label is removed and instead assertion is added at the top of the function. The type of return for the function is bool, so it fixes to return true and false instead of 1 and 0. Signed-off-by: Seung-Woo Kim

[PATCH v2 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

Hello Ville, Thanks for comment. On 2013? 07? 02? 17:29, Ville Syrj?l? wrote: > On Tue, Jul 02, 2013 at 09:52:02AM +0900, Seung-Woo Kim wrote: >> If raw_edid of drm_edid_block_vaild() is null, it will crash, so >> checking in bad label is removed and instead assertion is added at >> the top of

PCI device IDs for device needing the i915 invert_brightness quirk

Dear all, Recently I've come across this article about a probable fix for my laptop's black screen on boot: http://people.skolelinux.org/pere/blog/Fixing_the_Linux_black_screen_of_death_on_machines_with_Intel_HD_video.html I've tried the fix and it works perfectly so I'm contacting you as

[PATCH] drm/prime: fix up handle_to_fd ioctl return value

rime_fd = ret; > > > + ret = 0; > > > + } > > > + > > > goto out; > > > > > > fail_rm_handle: > > > -- > > > 1.7.10.4 > > > > > > > > > > Right, that's my mistake. > > I'll pay attention from now on! > > > > Thank you & best regards YJ > > Reviewed-by ? > > Cheers, Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch > ___ > 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/20130702/7d82fb07/attachment.html>

[PATCH] drm/prime: fix up handle_to_fd ioctl return value

top.org/mailman/listinfo/dri-devel -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130702/35fe13c8/attachment.html>

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600

On Tue, Jul 2, 2013 at 4:15 PM, J?rg-Volker Peetz wrote: > Alex Deucher wrote, on 07/02/2013 21:46: >> On Tue, Jul 2, 2013 at 10:09 AM, J?rg-Volker Peetz wrote: >>> With self-compiled linux 3.10 on a HP Pavilion dv7 with hybrid graphics (ATI >>> RS880M [Mobility Radeon HD 4200 Series] / ATI

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600

With self-compiled linux 3.10 on a HP Pavilion dv7 with hybrid graphics (ATI RS880M [Mobility Radeon HD 4200 Series] / ATI Manhattan [Mobility Radeon HD 5400 Series]) uvd seems to be broken. The new firware files are installed in /lib/firmware/radeon: sha1 hashes

[PATCH] drm/exynos: Add missing includes

sc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130702/d4c8cc03/attachment-0001.pgp>

"radeon: error initializing UVD" in kernel 3.10 on hybrid laptop with CEDAR / R600

On Tue, Jul 2, 2013 at 10:09 AM, J?rg-Volker Peetz wrote: > With self-compiled linux 3.10 on a HP Pavilion dv7 with hybrid graphics (ATI > RS880M [Mobility Radeon HD 4200 Series] / ATI Manhattan [Mobility Radeon HD > 5400 > Series]) uvd seems to be broken. > > The new firware files are installed

3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

On Tue, Jul 2, 2013 at 2:44 PM, Justin Piszcz wrote: > > > -Original Message- > From: Alex Deucher [mailto:alexdeucher at gmail.com] > Sent: Tuesday, July 02, 2013 2:36 PM > To: Justin Piszcz > Cc: linux-kernel at vger.kernel.org; dri-devel at lists.freedesktop.org > Subject: Re: 3.10

Best practice device tree design for display subsystems/DRM

On Tue, Jul 2, 2013 at 1:57 PM, Sebastian Hesselbarth wrote: > I am against a super node which contains lcd and dcon/ire nodes. You can > enable those devices on a per board basis. We add them to dove.dtsi but > disable them by default (status = "disabled"). > > The DRM driver itself should get a

3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

-Original Message- From: Alex Deucher [mailto:alexdeuc...@gmail.com] Sent: Tuesday, July 02, 2013 2:36 PM To: Justin Piszcz Cc: linux-kernel at vger.kernel.org; dri-devel at lists.freedesktop.org Subject: Re: 3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD

[PATCH] drm/exynos: fix pages allocation in lowlevel_buffer_allocate

On Tue, Jul 02, 2013 at 07:59:22PM +0900, Seung-Woo Kim wrote: > From: YoungJun Cho > > When drm iommu is not supported, buf->pages has to be allocated > and assigned to phys_to_page() result, which type is struct page *. > So it is sufficient to allocate buf->pages with multiple struct > page

3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

EDAR chipset) but FYI. Make sure you have the the latest CEDAR_rlc.bin in addition to CYPRESS_uvd.bin and make sure the latest images are available in your initrd or kernel image, etc. Alex > > Kernel config: > http://home.comcast.net/~jpiszcz/20130702/config-3.10-4.txt > > Full dmesg: > http:

3.10 kernel: [drm:evergreen_startup] *ERROR* radeon: error initializing UVD (-1).

initializing UVD (-1). The screen goes black for ~5 seconds and then come back on. Not sure if this has been reported or not (w/CEDAR chipset) but FYI. Kernel config: http://home.comcast.net/~jpiszcz/20130702/config-3.10-4.txt Full dmesg: http://home.comcast.net/~jpiszcz/20130702/full-dmesg.txt Po

[PATCH 1/6] drm: make drm_mm_init() return void

On Tue, Jul 2, 2013 at 5:22 AM, Daniel Vetter wrote: > On Mon, Jul 01, 2013 at 08:32:58PM +0200, David Herrmann wrote: >> There is no reason to return "int" as this function never fails. >> Furthermore, several drivers (ast, sis) already depend on this. >> >> Signed-off-by: David Herrmann > >

[PATCH] drm/nouveau: handle framebuffer pinning correctly

Unpinning wasn't always handled correctly. The crtc_disable and nouveau_fbcon_destroy calls needed to unpin but didn't, resulting in a pin leak. While debugging this I found some leaks in the error paths of nouveau_user_framebuffer_create, so I fixed those too. Signed-off-by: Maarten Lankhorst

[PATCH] drm: drm init call takes large time

On Sun, Jun 30, 2013 at 05:41:59AM +0500, Abbas Raza wrote: > From: Abbas Raza > > DRM_INFO calls in the drm init routines are causing a large delay at boot time > due to which imx_drm_init call average takes around 26 ms. Changing DRM_INFO > to > DRM_DEBUG reduces startup time to < 3ms.

[Bug 66317] FlightGear 2.10 crashes on load

RL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130702/099f1986/attachment.html>

Best practice device tree design for display subsystems/DRM

On Tue, Jul 2, 2013 at 12:43 PM, Russell King wrote: > I will point out that relying on driver probing orders has already been > stated by driver model people to be unsafe. This is why I will not > adopt such a solution for my driver; it is a bad design. Just to clarify, what you're objecting

[PATCH v3 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

On Tue, Jul 02, 2013 at 05:57:04PM +0900, Seung-Woo Kim wrote: > If raw_edid of drm_edid_block_vaild() is null, it will crash, so > checking in bad label is removed and instead assertion is added at > the top of the function. > The type of return for the function is bool, so it fixes to return >

[PATCH v2 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

On Tue, Jul 02, 2013 at 09:52:02AM +0900, Seung-Woo Kim wrote: > If raw_edid of drm_edid_block_vaild() is null, it will crash, so > checking in bad label is removed and instead assertion is added at > the top of the function. > The type of return for the function is bool, so it fixes to return >

[PATCH v4 3/3] drm: fix error routines in drm_open_helper

On Tue, Jul 02, 2013 at 09:53:28AM +0900, Seung-Woo Kim wrote: > From: YoungJun Cho > > There are missing parts to handle error in drm_open_helper(). > The priv->minor, assigned by idr_find() which can return NULL, > should be checked whether it is NULL or not before referencing it. > put_pid(),

[PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

On Tue, Jul 02, 2013 at 10:25:17AM +0100, Chris Wilson wrote: > On Tue, Jul 02, 2013 at 10:48:31AM +0200, Daniel Vetter wrote: > > Every other place properly checks whether we've managed to set > > up the stolen allocator at boot-up properly, with the exception > > of the cleanup code. Which

Best practice device tree design for display subsystems/DRM

Hi, I'm looking into implementing devicetree support in armada_drm and would like to better understand the best practice here. Adding DT support for a DRM driver seems to be complicated by the fact that DRM is not "hotpluggable" - it is not possible for the drm_device to be initialised without

[PATCH v2 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

On Tue, Jul 02, 2013 at 09:52:02AM +0900, Seung-Woo Kim wrote: > If raw_edid of drm_edid_block_vaild() is null, it will crash, so > checking in bad label is removed and instead assertion is added at > the top of the function. > The type of return for the function is bool, so it fixes to return >

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

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

[PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

Every other place properly checks whether we've managed to set up the stolen allocator at boot-up properly, with the exception of the cleanup code. Which results in an ugly *ERROR* Memory manager not clean. Delaying takedown at module unload time since the drm_mm isn't initialized at all. v2:

[Intel-gfx] [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

On Tue, Jul 02, 2013 at 09:13:34AM +0100, Chris Wilson wrote: > On Tue, Jul 02, 2013 at 09:58:45AM +0200, Daniel Vetter wrote: > > On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote: > > > On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: > > > > Every other place properly

[PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

On Tue, Jul 02, 2013 at 10:48:31AM +0200, Daniel Vetter wrote: > Every other place properly checks whether we've managed to set > up the stolen allocator at boot-up properly, with the exception > of the cleanup code. Which results in an ugly > > *ERROR* Memory manager not clean. Delaying takedown

[PATCH] drm/prime: fix up handle_to_fd ioctl return value

On Tue, Jul 02, 2013 at 04:55:16PM +0900, YoungJun Cho wrote: > Dear Daniel, > > On Jul 2, 2013 4:19 PM, "Daniel Vetter" wrote: > > > > In > > > > commit da34242e5e0638312130f5bd5d2d277afbc6f806 > > Author: YoungJun Cho > > Date: Wed Jun 26 10:21:42 2013 +0900 > > > > drm/prime: add

[PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: > Every other place properly checks whether we've managed to set > up the stolen allocator at boot-up properly, with the exception > of the cleanup code. Which results in an ugly > > *ERROR* Memory manager not clean. Delaying takedown

[Intel-gfx] [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote: > On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: > > Every other place properly checks whether we've managed to set > > up the stolen allocator at boot-up properly, with the exception > > of the cleanup code. Which

[PATCH v4 3/3] drm: fix error routines in drm_open_helper

From: YoungJun Cho There are missing parts to handle error in drm_open_helper(). The priv->minor, assigned by idr_find() which can return NULL, should be checked whether it is NULL or not before referencing it. put_pid(), drm_gem_release(), and

[PATCH v2 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

If raw_edid of drm_edid_block_vaild() is null, it will crash, so checking in bad label is removed and instead assertion is added at the top of the function. The type of return for the function is bool, so it fixes to return true and false instead of 1 and 0. Signed-off-by: Seung-Woo Kim

[patch] drm/radeon/dpm: cleanup a type issue with rv6xx_clocks_per_unit()

The rv6xx_clocks_per_unit() function pretends it can set flags in a u64 bitfield but really because "1" is an int it doesn't work for more than 32 bits. The only caller truncates the high bits away anyway. I've just changed it to be a u32. Signed-off-by: Dan Carpenter diff --git

armada_drm clock selection - try 2

On 07/02/13 03:57, Daniel Drake wrote: > On Mon, Jul 1, 2013 at 3:48 PM, Sebastian Hesselbarth > wrote: >> I prefer not to try to find the best clock (source) at all. Let the >> user pass the clock name by e.g. platform_data (or DT) and just try to >> get the requested pixclk or a integer

[patch] drm/radeon/dpm: off by one in si_set_mc_special_registers()

These checks should be ">=" instead of ">". j is used as an offset into the table->mc_reg_address[] array and that has SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE (16) elements. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c index

[PATCH] drm/prime: fix up handle_to_fd ioctl return value

In commit da34242e5e0638312130f5bd5d2d277afbc6f806 Author: YoungJun Cho Date: Wed Jun 26 10:21:42 2013 +0900 drm/prime: add return check for dma_buf_fd the failure case handling was fixed up. But in the case when we already had the buffer exported it changed the return value: Previously

[Intel-gfx] [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

On Tue, Jul 02, 2013 at 09:58:45AM +0200, Daniel Vetter wrote: > On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote: > > On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: > > > Every other place properly checks whether we've managed to set > > > up the stolen allocator at

[PATCH v3 3/3] drm: fix error routines in drm_open_helper

From: YoungJun Cho There are missing parts to handle error in drm_open_helper(). The priv->minor, assigned by idr_find() which can return NULL, should be checked whether it is NULL or not before referencing it. put_pid(), drm_gem_release(), and

[Bug 66425] "failed testing IB on ring 5" when suspending to disk

to this? Cause except for non working UVD it shouldn't affect the driver at all. -- 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/20130702/e97e058e/attachment.html>

[PATCH 2/3] drm: move edid null check to the first part of drm_edid_block_valid

Hi Daniel, On 2013? 07? 01? 23:56, Daniel Vetter wrote: > On Mon, Jul 1, 2013 at 12:21 PM, Chris Wilson > wrote: >> On Mon, Jul 01, 2013 at 07:06:32PM +0900, Seung-Woo Kim wrote: >>> If raw_edid is null, it will crash, so checking in bad label is >>> meaningless. >> >> It would be an error on

[PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: > Every other place properly checks whether we've managed to set > up the stolen allocator at boot-up properly, with the exception > of the cleanup code. Which results in an ugly > > *ERROR* Memory manager not clean. Delaying takedown

[PATCH] drm/nouveau: fix locking in nouveau_crtc_page_flip

On Mon, Jul 1, 2013 at 8:00 PM, Maarten Lankhorst wrote: > This is a bit messed up because chan->cli->mutex is a different class, > depending on whether it is the global drm client or not. This is > because the global cli->mutex lock can be taken for eviction, > so locking it before pinning the

linux-next: Tree for Jul 1 [ drm-intel-next: Several call-traces ]

On Mon, Jul 1, 2013 at 11:03 AM, Sedat Dilek wrote: > On Mon, Jul 1, 2013 at 10:52 AM, Daniel Vetter > wrote: >> On Mon, Jul 1, 2013 at 10:49 AM, Sedat Dilek >> wrote: >>> On Mon, Jul 1, 2013 at 9:59 AM, Stephen Rothwell >>> wrote: Hi all, Changes since 20130628:

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

> Of course, I share the idea of true, full-blown of_drm_something > helpers. But the DT patch, is not an improvement but a real fix as in > "make DRM not break on some platforms". From that on, I can start > digging into DRM API and improve DT support here and there. > > So for the three patches

RADEON / DPM: GPU cannot properly up-clock

2013/6/28 Joshua C. : > 2013/6/27 Alex Deucher : >> On Wed, Jun 26, 2013 at 4:57 PM, Joshua C. wrote: >>> 2013/6/26 Deucher, Alexander : > -Original Message- > From: Joshua C. [mailto:joshuacov at gmail.com] > Sent: Wednesday, June 26, 2013 1:52 PM > To:

[PATCH RFC 1/3] DRM: Armada: Add Armada DRM driver

On 07/01/2013 11:55 PM, Rob Clark wrote: > On Mon, Jul 1, 2013 at 4:52 AM, Sebastian Hesselbarth > wrote: >> - TDA998x irq handling - ignored >> - TDA998x sync fix - ignored > > At least the sync fix, looks like I missed it (it probably is a good > idea to CC me if you want me to look at it).

[pull] radeon drm-next-3.11

On 2013.07.01 at 17:01 -0400, alexdeucher at gmail.com wrote: > From: Alex Deucher > > Hi Dave, > > A few more patches for 3.11: > - add debugfs interface to check current DPM state > - Fix a bug that caused problems with DPM on BTC+ asics. > > The following changes since commit

armada_drm clock selection - try 2

On 07/01/2013 10:30 PM, Daniel Drake wrote: > Here is a new patch which should incorporate all your previous feedback. > Now each variant passes clock info to the main driver via a new > armada_clk_info structure. > > A helper function in the core lets each variant find the best clock. > As you

[patch] drm/radeon/dpm: off by one in si_set_mc_special_registers()

These checks should be = instead of . j is used as an offset into the table-mc_reg_address[] array and that has SMC_SISLANDS_MC_REGISTER_ARRAY_SIZE (16) elements. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c

[patch] drm/radeon/dpm: cleanup a type issue with rv6xx_clocks_per_unit()

The rv6xx_clocks_per_unit() function pretends it can set flags in a u64 bitfield but really because 1 is an int it doesn't work for more than 32 bits. The only caller truncates the high bits away anyway. I've just changed it to be a u32. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com

[PATCH] drm/prime: fix up handle_to_fd ioctl return value

In commit da34242e5e0638312130f5bd5d2d277afbc6f806 Author: YoungJun Cho yj44@samsung.com Date: Wed Jun 26 10:21:42 2013 +0900 drm/prime: add return check for dma_buf_fd the failure case handling was fixed up. But in the case when we already had the buffer exported it changed the

Re: [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: Every other place properly checks whether we've managed to set up the stolen allocator at boot-up properly, with the exception of the cleanup code. Which results in an ugly *ERROR* Memory manager not clean. Delaying takedown

Re: [PATCH] drm/prime: fix up handle_to_fd ioctl return value

Dear Daniel, On Jul 2, 2013 4:19 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: In commit da34242e5e0638312130f5bd5d2d277afbc6f806 Author: YoungJun Cho yj44@samsung.com Date: Wed Jun 26 10:21:42 2013 +0900 drm/prime: add return check for dma_buf_fd the failure case handling

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote: On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: Every other place properly checks whether we've managed to set up the stolen allocator at boot-up properly, with the exception of the cleanup code. Which results in

Re: [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: Every other place properly checks whether we've managed to set up the stolen allocator at boot-up properly, with the exception of the cleanup code. Which results in an ugly *ERROR* Memory manager not clean. Delaying takedown

Re: [PATCH] drm/prime: fix up handle_to_fd ioctl return value

On Tue, Jul 02, 2013 at 04:55:16PM +0900, YoungJun Cho wrote: Dear Daniel, On Jul 2, 2013 4:19 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: In commit da34242e5e0638312130f5bd5d2d277afbc6f806 Author: YoungJun Cho yj44@samsung.com Date: Wed Jun 26 10:21:42 2013 +0900

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

On Tue, Jul 02, 2013 at 09:58:45AM +0200, Daniel Vetter wrote: On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote: On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: Every other place properly checks whether we've managed to set up the stolen allocator at boot-up

Re: [PATCH] drm/prime: fix up handle_to_fd ioctl return value

Dear Daniel, On Jul 2, 2013 5:14 PM, Daniel Vetter dan...@ffwll.ch wrote: On Tue, Jul 02, 2013 at 04:55:16PM +0900, YoungJun Cho wrote: Dear Daniel, On Jul 2, 2013 4:19 PM, Daniel Vetter daniel.vet...@ffwll.ch wrote: In commit da34242e5e0638312130f5bd5d2d277afbc6f806

Re: [PATCH v2 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

On Tue, Jul 02, 2013 at 09:52:02AM +0900, Seung-Woo Kim wrote: If raw_edid of drm_edid_block_vaild() is null, it will crash, so checking in bad label is removed and instead assertion is added at the top of the function. The type of return for the function is bool, so it fixes to return true

[ANNOUNCE] libdrm 2.4.46

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Release because I want the cursor ioctls released, also haswell and radeon ids. Alex Deucher (3): radeon: add CIK chip families radeon: add Bonaire pci ids radeon: add kabini pci ids Damien Lespiau (3): intel/aub: Sync the

Re: [Intel-gfx] [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

On Tue, Jul 02, 2013 at 09:13:34AM +0100, Chris Wilson wrote: On Tue, Jul 02, 2013 at 09:58:45AM +0200, Daniel Vetter wrote: On Tue, Jul 02, 2013 at 08:54:30AM +0100, Chris Wilson wrote: On Mon, Jul 01, 2013 at 10:34:30PM +0200, Daniel Vetter wrote: Every other place properly checks

Re: [PATCH v2 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

Hello Ville, Thanks for comment. On 2013년 07월 02일 17:29, Ville Syrjälä wrote: On Tue, Jul 02, 2013 at 09:52:02AM +0900, Seung-Woo Kim wrote: If raw_edid of drm_edid_block_vaild() is null, it will crash, so checking in bad label is removed and instead assertion is added at the top of the

[PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

Every other place properly checks whether we've managed to set up the stolen allocator at boot-up properly, with the exception of the cleanup code. Which results in an ugly *ERROR* Memory manager not clean. Delaying takedown at module unload time since the drm_mm isn't initialized at all. v2:

[PATCH v3 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

If raw_edid of drm_edid_block_vaild() is null, it will crash, so checking in bad label is removed and instead assertion is added at the top of the function. The type of return for the function is bool, so it fixes to return true and false instead of 1 and 0. Signed-off-by: Seung-Woo Kim

[Bug 66425] failed testing IB on ring 5 when suspending to disk

https://bugs.freedesktop.org/show_bug.cgi?id=66425 Christian König deathsim...@vodafone.de changed: What|Removed |Added Status|NEW |ASSIGNED ---

Re: [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

On Tue, Jul 02, 2013 at 10:48:31AM +0200, Daniel Vetter wrote: Every other place properly checks whether we've managed to set up the stolen allocator at boot-up properly, with the exception of the cleanup code. Which results in an ugly *ERROR* Memory manager not clean. Delaying takedown

Re: [PATCH] drm/i915: Don't try to tear down the stolen drm_mm if it's not there

On Tue, Jul 02, 2013 at 10:25:17AM +0100, Chris Wilson wrote: On Tue, Jul 02, 2013 at 10:48:31AM +0200, Daniel Vetter wrote: Every other place properly checks whether we've managed to set up the stolen allocator at boot-up properly, with the exception of the cleanup code. Which results in

Re: [PATCH] drm: drm init call takes large time

On Sun, Jun 30, 2013 at 05:41:59AM +0500, Abbas Raza wrote: From: Abbas Raza abbas_r...@mentor.com DRM_INFO calls in the drm init routines are causing a large delay at boot time due to which imx_drm_init call average takes around 26 ms. Changing DRM_INFO to DRM_DEBUG reduces startup time

[PATCH] drm/exynos: fix pages allocation in lowlevel_buffer_allocate

From: YoungJun Cho yj44@samsung.com When drm iommu is not supported, buf-pages has to be allocated and assigned to phys_to_page() result, which type is struct page *. So it is sufficient to allocate buf-pages with multiple struct page pointer size. Signed-off-by: YoungJun Cho

Re: [PATCH v4 3/3] drm: fix error routines in drm_open_helper

On Tue, Jul 02, 2013 at 09:53:28AM +0900, Seung-Woo Kim wrote: From: YoungJun Cho yj44@samsung.com There are missing parts to handle error in drm_open_helper(). The priv-minor, assigned by idr_find() which can return NULL, should be checked whether it is NULL or not before referencing

Re: [PATCH v2 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

On Tue, Jul 02, 2013 at 09:52:02AM +0900, Seung-Woo Kim wrote: If raw_edid of drm_edid_block_vaild() is null, it will crash, so checking in bad label is removed and instead assertion is added at the top of the function. The type of return for the function is bool, so it fixes to return true

Re: [PATCH v3 2/3] drm: add assertion for checking null edid to drm_edid_block_valid

On Tue, Jul 02, 2013 at 05:57:04PM +0900, Seung-Woo Kim wrote: If raw_edid of drm_edid_block_vaild() is null, it will crash, so checking in bad label is removed and instead assertion is added at the top of the function. The type of return for the function is bool, so it fixes to return true

  1   2   >