[REPOST PATCH 4/8] android: convert sync to fence api, v5

android side out once there's real interest. The downside of that is that we may end up with two different ways to synchronize buffers if it turns out that we can't make Android (or other use-cases) work with DMA fence. However I don't think that justifies postponing this patch set indefinitely. 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/20140620/94d2464b/attachment.sig>

drm/i2c: tda998x: free the CEC device on encoder_destroy

Hello Jean-Francois Moine, This is a semi-automatic email about new static checker warnings. The patch fc275a74eb81: "drm/i2c: tda998x: free the CEC device on encoder_destroy" from Jan 25, 2014, leads to the following Smatch complaint: drivers/gpu/drm/i2c/tda998x_drv.c:1194

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

t; + }, { This patch should also be adding a device tree binding document for this panel. 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/20140620/ef38df6c/attachment.sig>

[Bug 80311] New: 3D acceleration is broken with recent llvm and git

ing 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/20140620/4bbaeb5c/attachment.html>

AGP GART clarifications, please!

On 20 June 2014 18:27, ?meric MASCHINO wrote: > 2014-06-20 2:06 GMT+02:00 Dave Airlie : >> So to run in AGP mode you need a chipset specific driver to manage the >> chipsets AGP GART and other features, that the GPU drivers can talk >> to. > > Do the GPU drivers then talk differently to the

[PATCH 5/5] drm/exynos: enable vsync interrupt while waiting for vblank

Hi All, On 18 June 2014 17:04, Rahul Sharma wrote: > mixer_wait_for_vblank function expects that the upcoming > vsync interrupt handler routine will clear the > wait_vsync_event atomic variable. > > For this to happen, interrupts should be enabled and > disabled properly. > > Signed-off-by:

[PATCH 1/2] drm/exynos/fbdev: don't set fix.smem/mmio_{start, len}

On Fri, Jun 20, 2014 at 7:59 AM, Siarhei Siamashka wrote: > > On Fri, 4 Apr 2014 17:22:01 +0800 > Daniel Kurtz wrote: > > > Kernel access to the eyxnos fbdev framebuffer is via its gem object's > > kernel mapping (kvaddr, stored in info->screen_base). > > > > User space access is provided by

[Bug 68151] Backlight brightness change causes freeze (radeon with KMS)

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

[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

Just ping, any comments? Thanks Tiejun On 2014/6/19 17:53, Tiejun Chen wrote: > Originally the reason to probe ISA bridge instead of Dev31:Fun0 > is to make graphics device passthrough work easy for VMM, that > only need to expose ISA bridge to let driver know the real > hardware underneath.

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

- > You are receiving this mail because: > > * You are the assignee for the bug. > > > > ___ > 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/20140620/b1f595f9/attachment-0001.html>

[PATCH] drm: fix NULL pointer access by wrong ioctl

Hi On Wed, Jun 18, 2014 at 8:33 AM, Zhaowei Yuan wrote: > If user uses wrong ioctl command with _IOC_NONE and argument size > greater than 0, it can cause NULL pointer access from memset of line > 463. If _IOC_NONE, don't memset to 0 for kdata. > > Signed-off-by: Zhaowei Yuan Reviewed-by:

[Bug 65121] Possible memory leak in qxl drm driver

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

[PATCH] drm/msm: Implement msm drm fb_mmap callback function

Re-send the patch to remove the unnecessary initialization and the comment > This change implements msm drm specific fb_mmap function for fb device > to properly map the fb address to userspace. > > Signed-off-by: Hai Li > Signed-off-by: Stephane Viau > --- > drivers/gpu/drm/msm/msm_fbdev.c |

[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

Il 19/06/2014 11:53, Tiejun Chen ha scritto: > so this mean that isa bridge is still represented with Dev31:Func0 > like the native OS. Furthermore, currently we're pushing VGA > passthrough support into qemu upstream, and with some discussion, > we wouldn't set the bridge class type and just

[RFC][PATCH] gpu:drm:i915:intel_detect_pch: back to check devfn instead of check class type

Well I have no clue about forwarding the intel gpu to virtualized hosts and also no idea who could review this really. There's been a bit a discussion around the iommu mapping forwarding and similar topics though. So I really wonder how well our driver works in this use case ... -Daniel On Fri,

[PATCH 0/3] Remove devm_request_and_ioremap()

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/20/2014 02:15 PM, Wolfram Sang wrote: > On Thu, Jun 19, 2014 at 07:59:57PM -0700, 'Greg Kroah-Hartman' > wrote: >> On Fri, Jun 20, 2014 at 11:36:03AM +0900, Jingoo Han wrote: >>> On Friday, June 20, 2014 3:49 AM, Wolfram Sang wrote:

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

ping. On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar wrote: > From: Rahul Sharma > > This patch adds ps8622 lvds bridge discovery code to the dp driver. > > Signed-off-by: Rahul Sharma > Signed-off-by: Ajay Kumar > --- > drivers/gpu/drm/exynos/exynos_dp_core.c |5 + > 1 file changed,

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

ping. On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar wrote: > From: Vincent Palatin > > This patch adds drm_bridge driver for parade DisplayPort > to LVDS bridge chip. > > Signed-off-by: Vincent Palatin > Signed-off-by: Andrew Bresticker > Signed-off-by: Sean Paul > Signed-off-by: Rahul

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

ping. On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar wrote: > exynos_dp supports a simple bridge chain with ptn3460 bridge > and an LVDS panel attached to it. > This patch creates the bridge chain with ptn3460 as the head > of the list and panel_binder being the tail. > > Signed-off-by: Ajay

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

ping. On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar wrote: > Modify the driver to invoke callbacks for the next bridge > in the bridge chain. > Also, remove the drm_connector implementation from ptn3460, > since the same is implemented using panel_binder. > > Signed-off-by: Ajay Kumar > --- >

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

ping. On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar wrote: > Add a dummy bridge which binds all of the drm_bridge callbacks > to corresponding drm_panel callbacks. > > In theory, this is just a glue layer for the last bridge and > the panel attached to it. > > This driver also implements the

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

ping. On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar wrote: > Add drm_panel controls to support powerup/down of the > eDP panel, if one is present at the sink side. > > Signed-off-by: Ajay Kumar > --- > .../devicetree/bindings/video/exynos_dp.txt|2 + >

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

ping. On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar wrote: > Add helper functions to create bridge chain and to call the > corresponding next_bridge functions. > > Signed-off-by: Ajay Kumar > Suggested-by: Rob Clark > --- > include/drm/drm_crtc.h | 72 >

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

ping. On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar wrote: > This patch adds a simple driver to handle all the LCD and LED > powerup/down routines needed to support eDP/LVDS panels. > > The LCD and LED units are usually powered up via regulators, > and almost on all boards, we will have a

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

ping. On Wed, Jun 11, 2014 at 11:57 PM, Ajay Kumar wrote: > Most of the panels need an init sequence as mentioned below: > -- poweron LCD unit/LCD_EN > -- start video data > -- poweron LED unit/BACKLIGHT_EN > And, a de-init sequence as mentioned below: > --

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

ping. On Wed, Jun 11, 2014 at 11:56 PM, Ajay Kumar wrote: > Move the DP training and video enable from the hotplug handler into > a seperate function and call the same during dpms ON. > > With existing code, DP HPD should be generated just few ms before > calling enable_irq in dp_poweron. > >

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

ping. On Wed, Jun 11, 2014 at 11:56 PM, Ajay Kumar wrote: > This series is based on exynos-drm-next branch of Inki Dae's tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > I have tested this after adding few DT changes for exynos5250-snow, > exynos5420-peach-pit

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

archives/dri-devel/attachments/20140620/3cb256cd/attachment.html>

[PATCH 0/3] Remove devm_request_and_ioremap()

On Friday, June 20, 2014 3:49 AM, Wolfram Sang wrote: > > Pretty much a year ago, Tushar cleaned up a lot of deprecated uses of > devm_request_and_ioremap, yet some remains are still left. Remove the last two > users, and let the function rest in peace. I'd suggest that this series is > picked up

[PATCH 14/9] drm: Kick start vblank interrupts at drm_vblank_on()

On Mon, Jun 02, 2014 at 11:15:51AM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > If the user is interested in getting accurate vblank sequence > numbers all the time they may disable the vblank disable timer > entirely. In that case it seems appropriate to kick start

[Intel-gfx] [PATCH v2 9/9] drm/i915: Leave interrupts enabled while disabling crtcs during suspend

On Mon, May 26, 2014 at 02:46:32PM +0300, ville.syrjala at linux.intel.com wrote: > From: Ville Syrj?l? > > The new watermaek update mechanism requires interrupts to work s/watermaek/watermark/ > correctly. Because of this we need interrupts while disabling crtcs > during suspend. So move the

[PATCH] drm/msm: Implement msm drm fb_mmap callback function

This change implements msm drm specific fb_mmap function for fb device to properly map the fb address to userspace. Signed-off-by: Hai Li Signed-off-by: Stephane Viau --- drivers/gpu/drm/msm/msm_fbdev.c | 38 -- 1 file changed, 36 insertions(+), 2

[PATCH 0/3] Remove devm_request_and_ioremap()

e: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140620/a3f4ece6/attachment-0001.sig>

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Fri, Jun 20, 2014 at 1:42 AM, Greg KH wrote: >> I'm actually concerned about this trend. Downgrading things to WARN_ON >> can allow a security bug in the kernel to continue to exist, for >> example, or make the error message disappear. > > A BUG_ON makes any error message disappear pretty

AGP GART clarifications, please!

2014-06-20 2:06 GMT+02:00 Dave Airlie : > So to run in AGP mode you need a chipset specific driver to manage the > chipsets AGP GART and other features, that the GPU drivers can talk > to. Do the GPU drivers then talk differently to the graphics card when there's a GART? I mean, are there

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On Fri, Jun 20, 2014 at 12:39 AM, H. Peter Anvin wrote: >>> Aside: This is a pet peeve of mine and recently I've switched to >>> rejecting all patch that have a BUG_ON, period. >> >> Please do, I have been for a few years now as well for the same reasons >> you cite. >> > > I'm actually concerned

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

On Fri, Jun 20, 2014 at 10:11 AM, Laszlo Kertesz wrote: > > On 6/20/2014 4:30 PM, bugzilla-daemon at freedesktop.org wrote: > > Comment # 25 on bug 72921 from Alex Deucher > > (In reply to comment #24) >> Created attachment 101420 [details] >> dmesg with working bapm patch >> >> I can confirm

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

On 19.06.2014 19:20, Marek Ol??k wrote: > Hi Michel, > > 3.15 doesn't contain Christian's fix yet, so it should be always > broken for everybody. The fix is currently only in 3.16. > > Alternatively, you can cherry-pick the fix to 3.15, but it doesn't > apply cleanly. That's a good point.

AGP GART clarifications, please!

On 20 June 2014 03:17, ?meric MASCHINO wrote: > DRI gurus, > > If I'm not mistaken, the current Linux graphics stack is as follows > (excluding Wayland protocol and LLVM or GLAMOR-based approaches): > > X11/OpenGL app -> libX/Mesa -> DDX driver/Mesa DRI module -> kernel > DRM -> hardware > >

[Bug 72921] DPM Power Cycle with AMD A8-6600K & MSI FM2-A55M-E33

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

[PATCH 0/3] Remove devm_request_and_ioremap()

that right now while I'm remembering it :) Yay, great! Thank you both! -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/

[REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

On 20 June 2014 04:19, Greg KH wrote: > On Thu, Jun 19, 2014 at 01:45:30PM -0400, Rob Clark wrote: >> On Thu, Jun 19, 2014 at 1:00 PM, Greg KH >> wrote: >> > On Thu, Jun 19, 2014 at 10:00:18AM -0400, Rob Clark wrote: >> >> On Wed, Jun 18, 2014 at 9:13 PM, Greg KH >> >> wrote: >> >> > On Wed,

[Bug 65121] Possible memory leak in qxl drm driver

https://bugzilla.kernel.org/show_bug.cgi?id=65121 --- Comment #11 from xerofoify at gmail.com --- It seems to be only the opener or maintainer of this subsystem who can close it. Cheers Nick -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 65121] Possible memory leak in qxl drm driver

https://bugzilla.kernel.org/show_bug.cgi?id=65121 --- Comment #10 from xerofoify at gmail.com --- Our you sure, other people seem to be able to do it with other bugs. Thanks Nick -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 65121] Possible memory leak in qxl drm driver

https://bugzilla.kernel.org/show_bug.cgi?id=65121 --- Comment #9 from Dave Airlie --- kernel bugzilla sucks I can't change bug states. -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 62541] Kernel oops/panic during system boot with systemd - "Unable to handle kernel NULL pointer dereference"

https://bugzilla.kernel.org/show_bug.cgi?id=62541 xerofoify at gmail.com changed: What|Removed |Added CC||xerofoify at gmail.com ---

[Bug 65121] Possible memory leak in qxl drm driver

https://bugzilla.kernel.org/show_bug.cgi?id=65121 xerofoify at gmail.com changed: What|Removed |Added CC||xerofoify at gmail.com ---

[PATCH 1/2] drm/exynos/fbdev: don't set fix.smem/mmio_{start,len}

On Fri, 4 Apr 2014 17:22:01 +0800 Daniel Kurtz wrote: > Kernel access to the eyxnos fbdev framebuffer is via its gem object's > kernel mapping (kvaddr, stored in info->screen_base). > > User space access is provided by mmap(), read() and write() of /dev/fb/fb0. > These functions also only use

[Bug 80235] Artifacts in kernel 3.16-rc1 and HD 7750

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140620/6acfe9b1/attachment.html>

[Bug 80235] Artifacts in kernel 3.16-rc1 and HD 7750

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140620/5d1e448f/attachment-0001.html>

[PATCH] gpu: ipu-v3: Kconfig: Remove SOC_IMX6SL from IMX_IPUV3_CORE Kconfig

From: Fabio Estevam SOC_IMX6SL does not have the IPU block, so remove it from the Kconfig entry. Signed-off-by: Fabio Estevam --- drivers/gpu/ipu-v3/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/ipu-v3/Kconfig