[drm] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_crtc.c:1175 drm_universal_plane_init()

Hi Rob, 0day kernel testing robot got the below dmesg and the first bad commit is git://people.freedesktop.org/~robclark/linux cold-fusion commit 4eb7eae00f39d53f64441d05161317eb5fd704a6 Author: Rob Clark AuthorDate: Sat Mar 15 12:37:16 2014 -0400 Commit: Rob Clark CommitDate: Wed May

[PATCH] drm: Missed clflushopt in drm_clflush_virt_range

On Thu, May 15, 2014 at 07:37:32AM -0700, H. Peter Anvin wrote: > On 05/15/2014 05:38 AM, Daniel Vetter wrote: > > On Wed, May 14, 2014 at 09:41:12AM -0600, Ross Zwisler wrote: > >> With this commit: > >> > >> 2a0788dc9bc4 x86: Use clflushopt in drm_clflush_virt_range > >> > >> If clflushopt is

[PATCH] drm/doc: Discourage usage of MODESET_CTL ioctl

Hi Daniel, Thank you for the patch. On Thursday 15 May 2014 15:00:08 Daniel Vetter wrote: > Leftover from the old days of ums and should be used any longer. Since > > commit 29935554b384b1b3a7377d6f0b03b21d18a61683 > Author: Laurent Pinchart > Date: Wed May 30 00:58:09 2012 +0200 > >

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

|a buffer|a buffer with Tesseract -- 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/20140515/4d7e4

[PATCH 4/4] acpi-video: Add use native backlight quirk for the ThinkPad W530

Like all of the other *30 ThinkPad models, the W530 has a broken acpi-video backlight control. Note in order for this to actually fix things on the ThinkPad W530 the commit titled: "nouveau: Don't check acpi_video_backlight_support() before registering backlight" is also needed.

[PATCH 3/4] acpi-video: Unregister the backlight device if a raw one shows up later

When video.use_native_backlight=1 and non intel gfx are in use, the raw backlight device of the gfx driver will show up after acpi-video has done its acpi_video_verify_backlight_support() check. This causes video.use_native_backlight=1 to not have the desired result. This patch fixes this by

[PATCH 2/4] backlight: Add backlight device (un)registration notification

Some firmware drivers, ie acpi-video want to get themselves out of the way (in some cases) when their also is a raw backlight device available. Due to module loading ordering being unknown, acpi-video cannot be certain that the backlight_device_registered(BACKLIGHT_RAW) it does for this is the

[PATCH 1/4] nouveau: Don't check acpi_video_backlight_support() before registering backlight

acpi_video_backlight_support() is supposed to be called by other (vendor specific) firmware backlight controls, not by native / raw backlight controls like nv_backlight. Userspace will normally prefer firmware interfaces over raw interfaces, so if acpi_video backlight support is present it will

[PATCH 0/4] Add backlight registration notification and use it in acpi-video

Hi all, Here is a patch series to make video.use_native_backlight work on laptops with nv gfx, at least on those were nv gfx have a raw backlight interface. I've tried this on my own somewhat old nv equipped laptop, but that does not have a raw backlight interface. I'm currently doing a scratch

[RFC V2 0/3] drm/bridge: panel and chaining

On Thu, May 15, 2014 at 6:04 PM, Daniel Vetter wrote: > On Thu, May 15, 2014 at 12:32:58PM +0200, Thierry Reding wrote: >> On Fri, May 09, 2014 at 09:59:34AM -0400, Rob Clark wrote: >> > On Fri, May 9, 2014 at 5:08 AM, Andrzej Hajda >> > wrote: >> [...] >> > > 4. And the last thing, it is more

[PATCH v3 1/3] phy: Add exynos-simple-phy driver

On 15 May 2014 19:11, Kishon Vijay Abraham I wrote: > > > On Thursday 15 May 2014 07:05 PM, Rahul Sharma wrote: >> Hi, >> >> On 15 May 2014 19:01, Bartlomiej Zolnierkiewicz >> wrote: >>> >>> Hi, >>> >>> On Thursday, May 15, 2014 12:47:21 AM Rahul Sharma wrote: From: Tomasz Stanislawski

[PATCH v3 1/3] phy: Add exynos-simple-phy driver

On Thursday 15 May 2014 07:05 PM, Rahul Sharma wrote: > Hi, > > On 15 May 2014 19:01, Bartlomiej Zolnierkiewicz > wrote: >> >> Hi, >> >> On Thursday, May 15, 2014 12:47:21 AM Rahul Sharma wrote: >>> From: Tomasz Stanislawski >>> >>> Add exynos-simple-phy driver to support a single register

[Bug 78453] [HAWAII] Get acceleration working

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

[PATCH v3 1/3] phy: Add exynos-simple-phy driver

Hi, On 15 May 2014 19:01, Bartlomiej Zolnierkiewicz wrote: > > Hi, > > On Thursday, May 15, 2014 12:47:21 AM Rahul Sharma wrote: >> From: Tomasz Stanislawski >> >> Add exynos-simple-phy driver to support a single register >> PHY interfaces present on Exynos4 SoC. >> >> Signed-off-by: Tomasz

[PATCH v4 3/3] s5p-tv: hdmi: use hdmiphy as PHY

From: Tomasz Stanislawski The HDMIPHY (physical interface) is controlled by a single bit in a power controller's regiter. It was implemented as clock. It was a simple but effective hack. This patch makes S5P-HDMI driver to control HDMIPHY via PHY interface.

[PATCH v4 2/3] drm: exynos: hdmi: use hdmiphy as PHY

From: Tomasz Stanislawski The HDMIPHY (physical interface) is controlled by a single bit in a power controller's regiter. It was implemented as clock. It was a simple but effective hack. This patch makes HDMI driver to control HDMIPHY via PHY interface. Signed-off-by:

[PATCH v4 1/3] phy: Add exynos-simple-phy driver

From: Tomasz Stanislawski Add exynos-simple-phy driver to support a single register PHY interfaces present on Exynos4 SoC. Signed-off-by: Tomasz Stanislawski Signed-off-by: Rahul Sharma --- .../devicetree/bindings/phy/samsung-phy.txt| 57 ++

[PATCH v4 0/3] phy: Add exynos-simple-phy driver

From: Rahul Sharma Changelog: v4: * Rename files to follow "phy-exynos-simple" names. * Rename Macros to this convention PHY_EXYNOS_SIMPLE_. * Added list of phy specifier values to documentation file. * Removed of_match_ptr from

[RFC 4/4] drm/i915: Switch to unified plane cursor handling

The DRM core will translate calls to legacy cursor ioctls into universal cursor calls automatically, so there's no need to maintain the legacy cursor support. This greatly simplifies the transition since we don't have to handle reference counting differently depending on which cursor interface

[RFC 3/4] drm/i915: Add intel_crtc_cursor_set_obj() to set cursor buffer

Refactor cursor buffer setting such that the code to actually update the cursor lives in a new function, intel_crtc_cursor_set_obj(), and takes a GEM object as a parameter. The existing legacy cursor ioctl handler, intel_crtc_cursor_set() will now perform the userspace handle lookup and then call

[RFC 2/4] drm: Allow drivers to register cursor planes with crtc

Universal plane support had placeholders for cursor planes, but didn't actually do anything with them. Save the cursor plane reference inside the crtc and update the cursor plane parameter from void* to drm_plane. Signed-off-by: Matt Roper --- drivers/gpu/drm/drm_crtc.c | 5 -

[RFC 1/4] drm: Support legacy cursor ioctls via universal planes when possible

If drivers support universal planes and have registered a cursor plane with the DRM core, we should use that universal plane support when handling legacy cursor ioctls. Drivers that transition to universal planes won't have to maintain separate legacy ioctl handling; drivers that don't transition

[RFC 0/4] Cursor support with universal planes

Cursor planes are a bit trickier to support via the universal plane interface than primary planes were. Legacy cursor ioctls take handles to driver buffers directly whereas the universal plane API takes drm_framebuffer's that represent a buffer; due to this mismatch it isn't possible to implement

[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences

Am 15.05.2014 17:58, schrieb Maarten Lankhorst: > op 15-05-14 17:48, Christian K?nig schreef: >> Am 15.05.2014 16:18, schrieb Maarten Lankhorst: >>> op 15-05-14 15:19, Christian K?nig schreef: Am 15.05.2014 15:04, schrieb Maarten Lankhorst: > op 15-05-14 11:42, Christian K?nig schreef:

[Bug 78453] [HAWAII] Get acceleration working

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

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

https://bugzilla.kernel.org/show_bug.cgi?id=75241 --- Comment #13 from Tasev Nikola --- Created attachment 136251 --> https://bugzilla.kernel.org/attachment.cgi?id=136251=edit dmesg broken 3.15-rc5 -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

https://bugzilla.kernel.org/show_bug.cgi?id=75241 --- Comment #12 from Tasev Nikola --- Created attachment 136241 --> https://bugzilla.kernel.org/attachment.cgi?id=136241=edit dmesg working 3.15-rc5 -- You are receiving this mail because: You are watching the assignee of the bug.

[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences

op 15-05-14 17:48, Christian K?nig schreef: > Am 15.05.2014 16:18, schrieb Maarten Lankhorst: >> op 15-05-14 15:19, Christian K?nig schreef: >>> Am 15.05.2014 15:04, schrieb Maarten Lankhorst: op 15-05-14 11:42, Christian K?nig schreef: > Am 15.05.2014 11:38, schrieb Maarten Lankhorst:

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

https://bugzilla.kernel.org/show_bug.cgi?id=75241 --- Comment #11 from Tasev Nikola --- Hi I just notice that the 3.15-rc5 will boot successfully only once in 5-6 attempt. When i try it the first time in sunday i was just lucky he boot at first time. I suspend resume this computer rater then

[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences

Am 15.05.2014 16:18, schrieb Maarten Lankhorst: > op 15-05-14 15:19, Christian K?nig schreef: >> Am 15.05.2014 15:04, schrieb Maarten Lankhorst: >>> op 15-05-14 11:42, Christian K?nig schreef: Am 15.05.2014 11:38, schrieb Maarten Lankhorst: > op 15-05-14 11:21, Christian K?nig schreef:

[RFC V3 2/3] drm/bridge: add a dummy panel driver to support lvds bridges

On Thu, May 15, 2014 at 1:43 PM, Thierry Reding wrote: > On Wed, May 14, 2014 at 11:39:30PM +0530, Ajay kumar wrote: > [...] >> >> >> diff --git >> >> >> a/Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt >> >> >> b/Documentation/devicetree/bindings/drm/bridge/bridge_panel.txt >>

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

https://bugzilla.kernel.org/show_bug.cgi?id=75241 --- Comment #10 from Tasev Nikola --- I'm compiling a patched kernel now. I will test it but to be shure i will need 4-5 day's probably, because i use the 3.15-rc5 from sunday and the problem appear only now. -- You are receiving this mail

[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences

op 15-05-14 15:19, Christian K?nig schreef: > Am 15.05.2014 15:04, schrieb Maarten Lankhorst: >> op 15-05-14 11:42, Christian K?nig schreef: >>> Am 15.05.2014 11:38, schrieb Maarten Lankhorst: op 15-05-14 11:21, Christian K?nig schreef: > Am 15.05.2014 03:06, schrieb Maarten Lankhorst:

[PATCH v3] drm/panel: Add support for EDT ETM0700G0DH6 and ET070080DH6 panels

On 05/15/2014 03:41 PM, Thierry Reding wrote: > On Thu, May 15, 2014 at 09:54:07AM -0600, Stephen Warren wrote: >> On 05/15/2014 04:54 AM, Thierry Reding wrote: >>> On Thu, May 15, 2014 at 12:25:47PM +0200, Philipp Zabel wrote: The EDT ETM0700G0DH6 and ET070080DH6 are 7" 800x480 panels,

[PATCH 2/2] drm/i915: Use new kms-native vblank functions

Only the low-level irq handling functions still use integer crtc indices with this. But fixing that will require a lot more sugery and some good ideas for backwards compat with old ums userspace. Both in drivers and in the drm core. Signed-off-by: Daniel Vetter ---

[PATCH 1/2] drm/irq: Add kms-native crtc interface functions

We need to start somewhere ... With this the only places left in i915 where we use pipe integers is in the interrupt handling code. And there it actually makes some amount of sense. v2: - Polish kerneldoc a bit (Thierry). - Drop "dev" parameter since it's unecessary. - Split out i915 changes

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

https://bugzilla.kernel.org/show_bug.cgi?id=75241 --- Comment #9 from Christian K?nig --- (In reply to Alex Deucher from comment #8) > Does this patch help: > http://lists.freedesktop.org/archives/dri-devel/2014-May/059469.html Unlikely. Tasev has an RS780, on those the feedback divider is

[PATCH v3 1/3] phy: Add exynos-simple-phy driver

Hi, On Thursday, May 15, 2014 12:47:21 AM Rahul Sharma wrote: > From: Tomasz Stanislawski > > Add exynos-simple-phy driver to support a single register > PHY interfaces present on Exynos4 SoC. > > Signed-off-by: Tomasz Stanislawski > Signed-off-by: Rahul Sharma > > --- >

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

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

[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences

Am 15.05.2014 15:04, schrieb Maarten Lankhorst: > op 15-05-14 11:42, Christian K?nig schreef: >> Am 15.05.2014 11:38, schrieb Maarten Lankhorst: >>> op 15-05-14 11:21, Christian K?nig schreef: Am 15.05.2014 03:06, schrieb Maarten Lankhorst: > op 14-05-14 17:29, Christian K?nig schreef:

[Bug 74751] resume from suspend broken with 3.15-rc1 and rc2 kernels

https://bugzilla.kernel.org/show_bug.cgi?id=74751 --- Comment #21 from Daniel Vetter --- Ok, the offending commit is actually 177cf92de4aa97ec1435987e91696ed8b5023130, at least that one matches the diff of your change. It references the other commit, but that's not the commit itself. For

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

https://bugzilla.kernel.org/show_bug.cgi?id=75241 Tasev Nikola changed: What|Removed |Added CC||tasev.stefanoska at skynet.be --- Comment

[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences

op 15-05-14 11:42, Christian K?nig schreef: > Am 15.05.2014 11:38, schrieb Maarten Lankhorst: >> op 15-05-14 11:21, Christian K?nig schreef: >>> Am 15.05.2014 03:06, schrieb Maarten Lankhorst: op 14-05-14 17:29, Christian K?nig schreef: >> +/* did fence get signaled after we enabled

[PATCH] drm/irq: kerneldoc polish

- Integrate into the drm DocBook - Disable kerneldoc for functions not exported to drivers. - Properly document the new drm_vblank_on|off and add cautious comments explaining when drm_vblank_pre|post_modesets shouldn't be used. - General polish and OCD. v2: Polish as suggested by Thierry.

[PATCH] drm/doc: Discourage usage of MODESET_CTL ioctl

Leftover from the old days of ums and should be used any longer. Since commit 29935554b384b1b3a7377d6f0b03b21d18a61683 Author: Laurent Pinchart Date: Wed May 30 00:58:09 2012 +0200 drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers it is a complete no-Op for kms drivers. v2: Fix up

[PATCH] drm: Missed clflushopt in drm_clflush_virt_range

On Wed, May 14, 2014 at 09:41:12AM -0600, Ross Zwisler wrote: > With this commit: > > 2a0788dc9bc4 x86: Use clflushopt in drm_clflush_virt_range > > If clflushopt is available on the system, we use it instead of clflush > in drm_clflush_virt_range. There were two calls to clflush in this >

[RFC V2 0/3] drm/bridge: panel and chaining

On Thu, May 15, 2014 at 12:32:58PM +0200, Thierry Reding wrote: > On Fri, May 09, 2014 at 09:59:34AM -0400, Rob Clark wrote: > > On Fri, May 9, 2014 at 5:08 AM, Andrzej Hajda > > wrote: > [...] > > > 4. And the last thing, it is more about the concept/design. drm_bridge, > > > drm_hw_block

[PATCH 1/4] Documentation: fix typos in drm docbook

From: Masanari Iida Fix spelling typo in DocBook/drm.tmpl Signed-off-by: Masanari Iida Signed-off-by: Randy Dunlap --- Documentation/DocBook/drm.tmpl | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) --- lnx-315-rc2.orig/Documentation/DocBook/drm.tmpl +++

[PATCH v3 1/3] phy: Add exynos-simple-phy driver

On 15 May 2014 13:12, Thierry Reding wrote: > On Thu, May 15, 2014 at 10:49:37AM +0530, Rahul Sharma wrote: >> Hi Thierry, >> >> On 15 May 2014 03:44, Thierry Reding wrote: >> > On Thu, May 15, 2014 at 12:47:21AM +0530, Rahul Sharma wrote: > [...] >> >> +#define HDMI_PHY 0 >> >> +#define

[PATCH 07/12] drm/irq: kerneldoc polish

On 15.05.2014 03:51, Daniel Vetter wrote: > @@ -964,8 +1005,13 @@ EXPORT_SYMBOL(drm_vblank_off); > > /** > * drm_vblank_on - enable vblank events on a CRTC > - * @dev: DRM device > + * @dev: drm device > * @crtc: CRTC in question > + * > + * This functions restores the vblank interrupt

[PATCH 06/12] drm/doc: Discourage usage of MODESET_CTL ioctl

On 15.05.2014 03:51, Daniel Vetter wrote: > Leftover from the old days of ums and should be used any longer. Since > > commit 29935554b384b1b3a7377d6f0b03b21d18a61683 > Author: Laurent Pinchart > Date: Wed May 30 00:58:09 2012 +0200 > > drm: Disallow DRM_IOCTL_MODESET_CTL for KMS drivers

[PATCH 08/12] drm/irq: Add kms-native crtc interface functions

On Thu, May 15, 2014 at 12:42 PM, Thierry Reding wrote: > On Thu, May 15, 2014 at 12:10:16PM +0200, Daniel Vetter wrote: >> On Thu, May 15, 2014 at 9:34 AM, Thierry Reding >> wrote: >> > This seems slightly backwards. Since drm_vblank_get() is what's being >> > deprecated here, wouldn't it make

[PATCH v3] drm/panel: Add support for EDT ETM0700G0DH6 and ET070080DH6 panels

; Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt Applied, thanks. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/697083ba/attachment.sig>

[PATCH v2] drm/panel: add support for EDT ET057090DHU panel

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

[PATCH 08/12] drm/irq: Add kms-native crtc interface functions

e: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/1f23d845/attachment.sig>

[PATCH] drm: Perform cmdline mode parsing during connector initialisation

On Thu, 15 May 2014 10:54:36 +0100 Chris Wilson wrote: > i915.ko has a custom fbdev initialisation routine that aims to preserve > the current mode set by the BIOS, unless overruled by the user. The > user's wishes are determined by what, if any, mode is specified on the > command line (via the

[RFC V2 0/3] drm/bridge: panel and chaining

vailable Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/b2e25225/attachment-0001.sig>

[deathsimple/drm-next-3.16][2/4] drm/radeon/hdmi: DCE3: clean ACR control

On Wed, May 14, 2014 at 5:27 PM, Rafa? Mi?ecki wrote: > What initially seemed to be a typo in fglrx (using register 0x740c > instead of 74dc) appeared to be a correct behavior. Without this > 0x740c reg operation DCE 3 doesn't work and it seems we got code for > that already in place. > Recent RE

[PATCH v3] drm/panel: Add support for EDT ETM0700G0DH6 and ET070080DH6 panels

The EDT ETM0700G0DH6 and ET070080DH6 are 7" 800x480 panels, which can be supported by the simple panel driver. Signed-off-by: Philipp Zabel --- Changes since v2: - Added device tree binding documentation. Do we really want to add one little file for each panel? ---

[PATCH 08/12] drm/irq: Add kms-native crtc interface functions

On Thu, May 15, 2014 at 9:34 AM, Thierry Reding wrote: > This seems slightly backwards. Since drm_vblank_get() is what's being > deprecated here, wouldn't it make more sense to write > drm_crtc_vblank_get() in terms of struct drm_crtc and make > drm_vblank_get() call that instead? I can't seem to

[Intel-gfx] [PATCH v3] drm/i915: restore backlight precision when converting from opregion

On Mon, 12 May 2014, Aaron Lu wrote: > On 05/04/2014 03:22 PM, Chris Wilson wrote: >> 32b * 32b = 32b >> >> n = (u64)level * freq; to avoid overflow as you claim. > > Updated patch to fix this problem is here, thanks! Pushed to -fixes with Chris' IRC r-b, thanks for the patch and review. BR,

[PATCH 07/12] drm/irq: kerneldoc polish

On Thu, May 15, 2014 at 01:44:04PM +0900, Michel D?nzer wrote: > On 15.05.2014 03:51, Daniel Vetter wrote: > > @@ -964,8 +1005,13 @@ EXPORT_SYMBOL(drm_vblank_off); > > > > /** > > * drm_vblank_on - enable vblank events on a CRTC > > - * @dev: DRM device > > + * @dev: drm device > > * @crtc:

[RFC V2 0/3] drm/bridge: panel and chaining

tion/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/f7e90997/attachment-0001.sig>

[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences

Am 15.05.2014 11:38, schrieb Maarten Lankhorst: > op 15-05-14 11:21, Christian K?nig schreef: >> Am 15.05.2014 03:06, schrieb Maarten Lankhorst: >>> op 14-05-14 17:29, Christian K?nig schreef: > +/* did fence get signaled after we enabled the sw irq? */ > +if >

[PATCH v2] drm/panel: add support for EDT ET057090DHU panel

From: Stefan Agner This panel is sold by Toradex for Colibri T20/T30 and Apalis T30 evaluation kits. Signed-off-by: Stefan Agner --- .../devicetree/bindings/panel/edt,et057090dhu.txt | 7 ++ drivers/gpu/drm/panel/panel-simple.c | 26 ++

[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences

op 15-05-14 11:21, Christian K?nig schreef: > Am 15.05.2014 03:06, schrieb Maarten Lankhorst: >> op 14-05-14 17:29, Christian K?nig schreef: +/* did fence get signaled after we enabled the sw irq? */ +if (atomic64_read(>rdev->fence_drv[fence->ring].last_seq) >= fence->seq)

[PATCH v2] drm/panel: Add support for EDT ETM0700G0DH6 and ET070080DH6 panels

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

[PATCH v3 1/3] phy: Add exynos-simple-phy driver

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

[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences

Am 15.05.2014 03:06, schrieb Maarten Lankhorst: > op 14-05-14 17:29, Christian K?nig schreef: >>> +/* did fence get signaled after we enabled the sw irq? */ >>> +if >>> (atomic64_read(>rdev->fence_drv[fence->ring].last_seq) >= >>> fence->seq) { >>> +

[PATCH] drm: Perform cmdline mode parsing during connector initialisation

i915.ko has a custom fbdev initialisation routine that aims to preserve the current mode set by the BIOS, unless overruled by the user. The user's wishes are determined by what, if any, mode is specified on the command line (via the video= parameter). However, that command line mode is first

[PATCH v2 4/7] drivers/base: Add interface framework

t probe time by the device drivers for the devices they drive. Even though this was designed with the above use-case in mind I can imagine this to be useful for other things as well. For example a set of generic interfaces could be created and devices (or even whole classes of devices) could be made to expose these interfaces. This would cause interfaces to be created for each of these devices. That's functionality similar to what can be done with notifiers, albeit somewhat more structured. That could for example be useful to apply policy to a class of devices or collect statistics, etc. If you think that I'm on a wild-goose chase, please let me know so that I don't waste any more time on this. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/cec82d64/attachment.sig>

[Intel-gfx] Design review request: DRM color manager

What I understood from the reviews comments from the experts, is having a central color management at DRM kernel layer is not a good idea, and we should create individual DRM properties for the color correction methods, and let the control be there in the user space level, where an atomic

[PATCH v3 1/3] phy: Add exynos-simple-phy driver

Hi Thierry, On 15 May 2014 03:44, Thierry Reding wrote: > On Thu, May 15, 2014 at 12:47:21AM +0530, Rahul Sharma wrote: > [...] >> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt >> b/Documentation/devicetree/bindings/phy/samsung-phy.txt > [...] >> +For

[PATCH v2] drm/panel: Add support for EDT ETM0700G0DH6 and ET070080DH6 panels

The EDT ETM0700G0DH6 and ET070080DH6 are 7" 800x480 panels, which can be supported by the simple panel driver. Signed-off-by: Philipp Zabel --- Changes since v1: - Added compatible for EDT ET070080DH6 panel, which is exactly the same panel minus the multitouch. ---

[RFC V3 2/3] drm/bridge: add a dummy panel driver to support lvds bridges

any new functions to DRM panel I'd like to see them properly documented. It needs to be defined precisely what the effect of these functions should be so that both panel driver writers know what to implement and display driver writers need to know when to call which function. Also, please let's not call them .pre_enable() and .post_disable(). The names should be something more specific to reflect what they are meant to do. Even something like .prepare() and .unprepare() would be better choices. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/7ebffebe/attachment.sig>

[PATCH v3] drm/panel: Add support for EDT ETM0700G0DH6 and ET070080DH6 panels

On 05/15/2014 04:54 AM, Thierry Reding wrote: > On Thu, May 15, 2014 at 12:25:47PM +0200, Philipp Zabel wrote: >> The EDT ETM0700G0DH6 and ET070080DH6 are 7" 800x480 panels, >> which can be supported by the simple panel driver. >> >> Signed-off-by: Philipp Zabel >> --- >> Changes since v2: >> -

[PATCH v3 1/3] phy: Add exynos-simple-phy driver

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

[PATCH 08/12] drm/irq: Add kms-native crtc interface functions

still prefer to have i915 changes in a separate commit, but otherwise: Reviewed-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/a73aaf70/attachment.sig>

[PATCH v3 1/3] phy: Add exynos-simple-phy driver

Thanks Tomasz, On 15 May 2014 01:31, Tomasz Figa wrote: > Hi Rahul, Tomasz, [snip] >> + simplephys: simple-phys at 1004 { >> + compatible = "samsung,exynos5250-simple-phy"; > > Missing reg property or unnecessary @unit-address suffix in node name. I should have removed

[deathsimple/drm-next-3.16][PATCH V2 4/4] drm/radeon/hdmi: DCE2: simplify audio workaround

Thanks to advanced RE of fglrx we finally know what exactly needs to be handled of AFMT change. This has been tested for possible regressions on: 1) DCE2 HD2400 (RV610) 2) DCE3 HD3470 (RV620) For a reference and details see: https://bugzilla.kernel.org/show_bug.cgi?id=76231 Signed-off-by: Rafa?

[deathsimple/drm-next-3.16][PATCH V2 3/4] drm/radeon/hdmi: DCE2: update setmode

Recent RE efforts revealed ops performed by fglrx during HDMI setup. This mostly adds masks to r/w ops plus few single missing bits. This has been tested for possible regressions on: 1) DCE2 HD2400 (RV610) 2) DCE3 HD3470 (RV620) For a reference and details see:

[PATCH 07/12] drm/irq: kerneldoc polish

a crtc. This function ensures that the latest vblank frame > count is > + * stored so that drm_vblank_on can restore it again. drm_vblank_on() to have it correctly highlighted? Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/e240ce47/attachment-0001.sig>

[Intel-gfx] Design review request: DRM color manager

bbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140515/40ef3b0b/attachment.sig>

[Intel-gfx] Design review request: DRM color manager

Sounds good to me. Regards Shashank -Original Message- From: Thierry Reding [mailto:thierry.red...@gmail.com] Sent: Thursday, May 15, 2014 12:36 PM To: Sharma, Shashank Cc: Daniel Vetter; intel-gfx; dri-devel; Purushothaman, Vijay A; Mukherjee, Indranil; Shankar, Uma; Jindal, Sonika;

[PATCH] drm: Missed clflushopt in drm_clflush_virt_range

On 05/15/2014 05:38 AM, Daniel Vetter wrote: > On Wed, May 14, 2014 at 09:41:12AM -0600, Ross Zwisler wrote: >> With this commit: >> >> 2a0788dc9bc4 x86: Use clflushopt in drm_clflush_virt_range >> >> If clflushopt is available on the system, we use it instead of clflush >> in

[Bug 78717] radeon: Failed to allocate a buffer

ves/dri-devel/attachments/20140515/185da0e2/attachment.html>

[RFC PATCH v1 08/16] drm/radeon: use common fence implementation for fences

op 14-05-14 17:29, Christian K?nig schreef: >> +/* did fence get signaled after we enabled the sw irq? */ >> +if (atomic64_read(>rdev->fence_drv[fence->ring].last_seq) >= >> fence->seq) { >> +radeon_irq_kms_sw_irq_put(fence->rdev, fence->ring); >> +return false; >> +}

[Bug 78717] radeon: Failed to allocate a buffer

es/dri-devel/attachments/20140515/9eb71ee3/attachment-0001.html>

[Bug 78464] black rectangles when running Battlefield Bad Company 2 on Wine

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/20140515/7f06a260/attachment.html>

[Bug 78717] New: radeon: Failed to allocate a buffer

seems to hang the entire machine -- 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/20140515/521356ed/attachment.html>

[PATCH v3 3/3] s5p-tv: hdmi: use hdmiphy as PHY

From: Tomasz Stanislawski The HDMIPHY (physical interface) is controlled by a single bit in a power controller's regiter. It was implemented as clock. It was a simple but effective hack. This patch makes S5P-HDMI driver to control HDMIPHY via PHY interface.

[PATCH v3 2/3] drm: exynos: hdmi: use hdmiphy as PHY

From: Tomasz Stanislawski The HDMIPHY (physical interface) is controlled by a single bit in a power controller's regiter. It was implemented as clock. It was a simple but effective hack. This patch makes HDMI driver to control HDMIPHY via PHY interface. Signed-off-by:

[PATCH v3 1/3] phy: Add exynos-simple-phy driver

From: Tomasz Stanislawski Add exynos-simple-phy driver to support a single register PHY interfaces present on Exynos4 SoC. Signed-off-by: Tomasz Stanislawski Signed-off-by: Rahul Sharma --- .../devicetree/bindings/phy/samsung-phy.txt| 56 ++

[PATCH v3 0/3] phy: Add exynos-simple-phy driver

From: Rahul Sharma Hi All, This series has been originally proposed by Tomasz Stanislawski. With his permission, I have addressed the following review comments in V3. Changelog: v3: * Implement lazy-init of PHYs. * Use MACROs instead of numbers to

[PATCH v3 1/3] phy: Add exynos-simple-phy driver

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

[Bug 78453] [HAWAII] Get acceleration working

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

[PATCH] imx-drm: imx-hdmi: move memory and resource allocation into probe function

On Wed, May 14, 2014 at 11:24:14PM +0200, Philipp Zabel wrote: > Move memory allocation and resource acquisition from the bind function into > the probe function. This calls the devres managed functions once instead of > possibly multiple times in the bind function and avoids leaking memory (as >

[RFC V3 2/3] drm/bridge: add a dummy panel driver to support lvds bridges

On Wed, May 14, 2014 at 8:24 PM, Thierry Reding wrote: > On Tue, May 13, 2014 at 10:19:33PM +0530, Ajay kumar wrote: >> On Tue, May 13, 2014 at 1:35 PM, Thierry Reding >> wrote: >> > On Fri, May 09, 2014 at 08:23:01PM +0530, Ajay Kumar wrote: >> >> implement basic panel controls as a drm_bridge

[deathsimple/drm-next-3.16][4/4] drm/radeon/hdmi: DCE2: simplify audio workaround

Thanks to advanced RE of fglrx we finally know what exactly needs to be handled of AFMT change. This has been tested for possible regressions on: 1) DCE2 D2400 (RV610) 2) DCE3 HD3470 (RV620) For a reference and details see: https://bugzilla.kernel.org/show_bug.cgi?id=76231 Signed-off-by: Rafa?

[deathsimple/drm-next-3.16][3/4] drm/radeon/hdmi: DCE2: update setmode

Recent RE efforts revealed ops performed by fglrx during HDMI setup. This mostly adds masks to r/w ops plus few single missing bits. This has been tested for possible regressions on: 1) DCE2 D2400 (RV610) 2) DCE3 HD3470 (RV620) For a reference and details see:

  1   2   >