[Bug 72621] X crash while video playback in web browsers with enabled rendering hardware acceleration

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

[RFC 3/4] drm: exynos: add IELCD post processor

c_end - > in_mode->crtc_hsync_start; > > + ielcd->hbpd = in_mode->crtc_htotal - in_mode->crtc_hsync_end; > > + ielcd->hfpd = in_mode->crtc_hsync_start - in_mode->crtc_hdisplay; > > +} > > + > > +static struct exynos_fimd_pp_ops ielcd_ops = { > > + .power_on = exynos_ielcd_power_on, > > + .power_off =exynos_ielcd_display_off, > > + .mode_set = exynos_ielcd_mode_set, > > +}; > > + > > +static struct exynos_fimd_pp ielcd_pp = { > > + .ops = _ops, > > +}; > > + > > +int exynos_ielcd_init(struct device *dev, struct exynos_fimd_pp **pp) > > +{ > > + struct device_node *ielcd_np; > > + struct ielcd_context *ielcd; > > + u32 addr[2]; > > + int ret = 0; > > + > > + ielcd = kzalloc(sizeof(struct ielcd_context), GFP_KERNEL); > > + if (!ielcd) { > > + DRM_ERROR("failed to allocate ielcd\n"); > > + ret = -ENOMEM; > > + goto error0; > > return directly from here and delete the label. > > Ok. > -- > With warm regards, > Sachin > Will address all your comments in next patchset. Thanks and regards, Ajay kumar -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/3f61d4ce/attachment.html>

[PATCH 4/4] drm/radeon/dp: switch to the common i2c over aux code

Provides a nice cleanup in radeon. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/atombios_dp.c | 117 + drivers/gpu/drm/radeon/radeon_connectors.c | 44 ++- drivers/gpu/drm/radeon/radeon_display.c| 11 ++-

[PATCH 3/4] drm/dp/i2c: use new BARE_ADDRESS flags in i2c over aux

We need bare address packets at the start and end of each i2c over aux transaction to properly reset the connection between transactions. This mirrors what the existing dp i2c over aux algo currently does. This fixes EDID fetches on certain monitors especially with dp bridges. Signed-off-by:

[PATCH 2/4] drm/radeon/dp: handle the new BARE_ADDRESS aux flag

Needed for proper i2c over aux handling for certain monitors and configurations (e.g., dp bridges or adapters). Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/atombios_dp.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git

[PATCH 1/4] drm/dp: add flags field to drm_dp_aux_msg struct

This adds a flags field and a new flag, BARE_ADDRESS, which drivers can use for special handling when they want to set just the aux address. This is needed to properly reset the connection between i2c transactions. Signed-off-by: Alex Deucher --- include/drm/drm_dp_helper.h | 3 +++ 1 file

[PATCH 1/3] drm/dp: make aux retries less chatty

Am 21.03.2014 15:34, schrieb Alex Deucher: > Switch to debug only to avoid flooding the logs. > This mirrors the behavior in some other drivers. > > Signed-off-by: Alex Deucher > Reviewed-by: Daniel Vetter Added to my 3.15 queue

[RFC 2/4] drm: exynos: add MDNIE post processor

t; > Ok. > > + } > > + > > + if (of_property_read_u32_array(mdnie_np, "reg", buf, 2)) { > > + DRM_ERROR("failed to get base address for MDNIE\n"); > > + ret = -ENOMEM; > > + goto err0; > > ditto > Ok. > > > + } > > + > > + mdnie = kzalloc(sizeof(struct mdnie_context), GFP_KERNEL); > > nit: use sizeof(*mdnie) > > Ok. > > + if (!mdnie) { > > + DRM_ERROR("failed to allocate mdnie\n"); > > This message is not needed as kzalloc prints OOM message upon failure. > Ok. > > > + ret = -ENOMEM; > > + goto err0; > > + } > > return directly. Ok. > > > + > > + mdnie->exynos_mdnie_base = ioremap(buf[0], buf[1]); > > + if (!mdnie->exynos_mdnie_base) { > > + DRM_ERROR("failed to ioremap mdnie device\n"); > > + ret = -ENOMEM; > > + goto err1; > > + } > > + > > + if (dt_parse_disp1blk_cfg(dev, _phyaddr)) { > > + DRM_ERROR("failed to get disp1blk property.\n"); > > + ret = -ENODEV; > > + goto err1; > > + } > > + > > + if (exynos_iomap_disp1blk(mdnie, disp1blk_phyaddr)) { > > + DRM_ERROR("failed to iopmap disp1blk sysreg.\n"); > > s/iopmap/iomap > > Ok. > > -- > With warm regards, > Sachin > I will address your comments in next patchset. Thanks, Ajay -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/067c570b/attachment-0001.html>

[PATCH 1/3] drm/dp: make aux retries less chatty

On Fri, Mar 21, 2014 at 10:34:06AM -0400, Alex Deucher wrote: > Switch to debug only to avoid flooding the logs. > This mirrors the behavior in some other drivers. > > Signed-off-by: Alex Deucher > Reviewed-by: Daniel Vetter Btw I've just noticed that we have a 2nd retry loop with 3 retries

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

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

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

(sd_festival) dumped core. -- 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/20140321/11344596/attachment.html>

[PATCH 2/2] drm/fb-helper: improve drm_fb_helper_initial_config locking

ble URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/9be15d52/attachment.sig>

[PATCH 1/2] drm/crtc-helper: fix locking for drm_helper_disable_unused_functions

lists.freedesktop.org/archives/dri-devel/attachments/20140321/9c7eabd8/attachment.sig>

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140321/f56fd1cd/attachment-0001.html>

[GIT PULL] exynos-drm-next

Hi Dave, This pull request includes some features and big changes for 3.15. Highlights -- Re-factoring works over the exynos drm framework. - drm_crtc, drm_encoder/drm_connector are implemented by sub drivers directly. - Removing pm interfaces from each sub driver, and

I915: OOPSes on linux-3.14-rc7

n = %u\n", clock->p1, clock->p2, > + clock->n); > if (WARN_ON(clock->n + 2 == 0 || clock->p == 0)) > return; > clock->vco = DIV_ROUND_CLOSEST(refclk * clock->m, clock->n + 2); > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Peter -- next part -- A non-text attachment was scrubbed... Name: dmesg.gz Type: application/x-gzip Size: 73573 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/9dcf27f3/attachment-0001.bin>

[Bug 70171] 3.13.x: kernel/time/tick-broadcast.c:668 exception, no sound, HDMI overscan issue

https://bugzilla.kernel.org/show_bug.cgi?id=70171 Andreas changed: What|Removed |Added Summary|kernel/time/tick-broadcast. |3.13.x: |c:668 exception and

[Bug 70171] kernel/time/tick-broadcast.c:668 exception and no sound

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

[PATCH] drm/exynos: remove DRIVER_HAVE_IRQ feature

On 03/21/2014 03:53 PM, Daniel Kurtz wrote: > On Fri, Mar 21, 2014 at 2:39 PM, Joonyoung Shim > wrote: >> Exynos drm driver cannot support DRIVER_HAVE_IRQ feature because it uses >> driver specific one instead of routine of drm framework to >> install/uninstall irq handler. > Wouldn't that break

I915: OOPSes on linux-3.14-rc7

On Fri, Mar 21, 2014 at 12:26:51PM +0100, Peter Senna Tschudin wrote: > On Thu, Mar 20, 2014 at 10:17 PM, Daniel Vetter wrote: > > On Thu, Mar 20, 2014 at 05:56:20PM +0100, Peter Senna Tschudin wrote: > >> When Fedora updated the Kernel package from 3.12 to 3.13 my notebook > >> stopped booting

[PATCH] drm/exynos: remove DRIVER_HAVE_IRQ feature

Exynos drm driver cannot support DRIVER_HAVE_IRQ feature because it uses driver specific one instead of routine of drm framework to install/uninstall irq handler. Signed-off-by: Joonyoung Shim --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 3 +-- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10

[PATCH 0/9] Doc/DT: DT bindings for various display components

On Mon, 17 Mar 2014 15:55:27 +0200, Tomi Valkeinen wrote: > Hi Grant, > > Ping. > > Are you fine with me proceeding with the current V4L2 port/endpoint > bindings? Sorry, this thread didn't make it past my email filters. Yes, go ahead. g.

[PATCH] drm/exynos: remove DRIVER_HAVE_IRQ feature

On Fri, Mar 21, 2014 at 2:39 PM, Joonyoung Shim wrote: > Exynos drm driver cannot support DRIVER_HAVE_IRQ feature because it uses > driver specific one instead of routine of drm framework to > install/uninstall irq handler. Wouldn't that break synchronous drm_wait_vblank()? (drm_wait_vblank

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

lps? -- 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/20140321/d63cf2cc/attachment.html>

[linux-next] WARNING at drm_mode_connector_list_update

ttm crc32c_intel drm broadcom microcode psmouse evdev lpc_ich tg3 battery i2c_i801 button processor ac wmi ipv6 ehci_pci ehci_hcd usbcore sr_mod cdrom sd_mod ahci [ 14.750668] CPU: 2 PID: 189 Comm: systemd-udevd Tainted: G W 3.14.0-rc7-next-20140321-dbg-dirty #192 [ 14.751152] Hardware

[PATCH v2] drm/i2c: tda998x: Change the compatible strings

On 03/21/2014 11:55 AM, Jean-Francois Moine wrote: > The tda998x driver accepts only 3 chips from the TDA998x family. > This patch changes the driver compatible strings to these chips. Jean-Francois, be careful with building a DT binding from a Linux driver. Although we constantly struggle to

[PATCH] ARM: dts: exynos4210-universal: add fimd polarization settings

Hi Andrzej, 2014-03-20 22:26 GMT+09:00 Andrzej Hajda : > The patch adds polarization flags to fimd node. > It fixes parallel display support. > > Signed-off-by: Andrzej Hajda > --- > Hi Inki, > > Since polarization patches were not merged, polarization > settings should be provided to fimd via

[Bug 76223] [radeonsi] luxmark segfault

? -- 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/20140321/65dc0ad5/attachment.html>

[RFC 3/4] drm: exynos: add IELCD post processor

On 19 March 2014 19:52, Ajay Kumar wrote: > Add post processor ops for IELCD and their support functions. > Expose an interface for the FIMD to register IELCD PP. [snip] > + > +#define exynos_ielcd_readl(addr) readl(ielcd->exynos_ielcd_base + addr) > +#define exynos_ielcd_writel(addr, val)

[PATCH] drm/ttm: remove fence_lock

On 03/21/2014 01:12 PM, Maarten Lankhorst wrote: > Hey, > > op 21-03-14 09:27, Thomas Hellstrom schreef: >> On 03/21/2014 12:55 AM, Dave Airlie wrote: >>> On Fri, Oct 19, 2012 at 3:04 AM, Jerome Glisse >>> wrote: On Thu, Oct 18, 2012 at 06:43:40PM +0200, Thomas Hellstrom wrote: > On

[linux-next] WARNING at drm_mode_connector_list_update

ainted: GW 3.14.0-rc7-next-20140321-dbg-dirty #189 [ 18.704481] Hardware name: Acer Aspire 5741G/Aspire 5741G , BIOS V1.20 02/08/2011 [ 18.704482] 88015217f830 813ba2d7 [ 18.704484] 88015217f868 fff

[linux-next] WARNING at drm_mode_connector_list_update

lpc_ich i2c_i801 ipv6 ehci_pci ehci_hcd usbcore sr_mod cdrom sd_mod ahci [ 18.707087] CPU: 2 PID: 175 Comm: systemd-udevd Tainted: GW 3.14.0-rc7-next-20140321-dbg-dirty #189 [ 18.707088] Hardware name: Acer Aspire 5741G/Aspire 5741G , BIOS V1.20 02/08/2011

[PATCH] drm/ttm: remove fence_lock

Hey, op 21-03-14 09:27, Thomas Hellstrom schreef: > On 03/21/2014 12:55 AM, Dave Airlie wrote: >> On Fri, Oct 19, 2012 at 3:04 AM, Jerome Glisse wrote: >>> On Thu, Oct 18, 2012 at 06:43:40PM +0200, Thomas Hellstrom wrote: On 10/18/2012 04:45 PM, Maarten Lankhorst wrote: > Op 18-10-12

[pci] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_crtc.c:94 drm_warn_on_modeset_not_all_locked()

On Thu, Mar 20, 2014 at 8:09 PM, Fengguang Wu wrote: > // CC Stephane for RAPL related bug > > Bjorn, sorry this bug report is mis-titled. The only new bug that show > up in aa11fc58dc is on rapl_pmu_init. And it shows up only 1 time, so > it's hard to reproduce and the bisect is likely not

[PATCH RFC 26/46] drivers/base: provide an infrastructure for componentised subsystems

On Fri, Mar 07, 2014 at 12:24:33AM +0100, Laurent Pinchart wrote: > However, we (as in the V4L2 community, and me personally) would have > appreciated to be CC'ed on the proposal. As you might know we already had a > solution for this problem, albeit V4L2-specific, in drivers/media/v4l2- >

I915: OOPSes on linux-3.14-rc7

intel_fbdev_initial_config+0x21/0x30 [i915] >> [] i915_driver_load+0xdde/0xe10 [i915] >> [] drm_dev_register+0x7b/0x160 [drm] >> [] drm_get_pci_dev+0xa0/0x220 [drm] >> [] i915_pci_probe+0x3b/0x60 [i915] >> [] local_pci_probe+0x45/0xa0 >> [] pci_device_pro

Intel G41 doesn't see any screens connected after suspend/resume

On Thu, Mar 20, 2014 at 07:17:00PM -0400, Nikolay Martynov wrote: > Yes, that seem to help. It didn't freeze anymore in 15 mins I used it. > Thanks! Thanks indeed, commit 3f5e0f06a3355a77ace053b4ffc0ac1c413cf2d0 Author: Chris Wilson Date: Fri Mar 21 07:40:56 2014 + drm/i915: Fix

[PATCH v2] drm/i2c: tda998x: Change the compatible strings

The tda998x driver accepts only 3 chips from the TDA998x family. This patch changes the driver compatible strings to these chips. Signed-off-by: Jean-Francois Moine --- v2: change the subject to drm/i2c This patch applies after drm/i2c: tda998x: Fix lack of required reg in DT

[PATCH v3] drm/i2c: tda998x: Fix lack of required reg in DT documentation

The I2C address (reg) is required for the TDA998x driver to be loaded and initialized. Signed-off-by: Jean-Francois Moine --- - v3 - change subject to drm/i2c - v2 - don't force the I2C address to be 0x70 This patch applies to linux-next. ---

[BUG] Circular locking dependency - DRM/CMA/MM/hotplug/...

On 2/18/2014 9:44 AM, Michal Nazarewicz wrote: >> On 2014-02-12 17:33, Russell King - ARM Linux wrote: >>> What if we did these changes: >>> >>> struct page *dma_alloc_from_contiguous(struct device *dev, int count, >>> unsigned int align) >>> { >>> ... >>>

[PATCH RFC v2 0/6] drm/i2c: Move tda998x to a couple encoder/connector

The 'slave encoder' structure of the tda998x driver asks for glue between the DRM driver and the encoder/connector structures. Changing the tda998x driver to a simple encoder/connector simplifies the code of the tilcdc driver. This change is permitted by Russell's infrastructure for componentised

[PATCH RFC v2 0/6] drm/i2c: Move tda998x to a couple encoder/connector

On Fri, Mar 21, 2014 at 11:27:45AM +0100, Jean-Francois Moine wrote: > The 'slave encoder' structure of the tda998x driver asks for glue > between the DRM driver and the encoder/connector structures. Given how close we are to the coming merge window, that the discussion about the of-graph

more locking fail...

On Fri, Mar 21, 2014 at 9:25 AM, Dave Airlie wrote: > There's one in i915 lvds on ironlake, and one in nouveau later. > > drm_mode_probed_add locking? > > but also others in suspend/resume paths. > So I've been nice, and fixes the suspend/resume one, but the edid one looks like a bit more

[PATCH RFC v2 1/6] drm/i2c: tda998x: Add the required port property

According to the media video interface, the video source and sink ports must be identified by mutual phandles. This patch adds the 'port' property of the tda998x (sink side). Signed-off-by: Jean-Francois Moine --- Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 11 ++- 1 file

[PATCH] drm/helper: lock all around force mode restore

From: Dave Airlie Since Daniel documented things with a sledge hammer, we got lots of nice backtraces in suspend/resume operations, I've check the callers of this and they all seems safe to me, This fixes one set of warns I reported. Signed-off-by: Dave Airlie ---

3.14 radeon regression: radeon is broken (pci bug?)

On Thu, Mar 20, 2014 at 10:17 PM, Andy Lutomirski wrote: > My system works on a 3.13 Fedora kernel. It does not work on a > more-or-less identically configured 3.14-rc7+ kernel. The symptom is > that the Plymouth password prompt flashes and them the screen goes > blank. Hitting escape brings

3.14 radeon regression: radeon is broken (pci bug?)

On Fri, Mar 21, 2014 at 9:49 AM, Andy Lutomirski wrote: > On Fri, Mar 21, 2014 at 7:41 AM, Alex Deucher > wrote: >> On Thu, Mar 20, 2014 at 10:17 PM, Andy Lutomirski >> wrote: >>> My system works on a 3.13 Fedora kernel. It does not work on a >>> more-or-less identically configured 3.14-rc7+

[PATCH 3/3] drm/radeon: use drm_dp_dpcd_read_link_status()

Replace the radeon specific version with the generic version. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/atombios_dp.c | 30 +- 1 file changed, 5 insertions(+), 25 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_dp.c

[PATCH 2/3] drm/radeon: use the new drm helpers for dp aux

Switch to the new dp helpers. The main difference is that the DP helpers don't allow an adjustable delay in the aux transaction, but I don't know that this is necessary. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/atombios_dp.c | 192 +

[PATCH 1/3] drm/dp: make aux retries less chatty

Switch to debug only to avoid flooding the logs. This mirrors the behavior in some other drivers. Signed-off-by: Alex Deucher Reviewed-by: Daniel Vetter --- drivers/gpu/drm/drm_dp_helper.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c

[PATCH RFC v2 3/6] drm/tilcd: dts: Add the video output port

The connection between the video source and sink must follow the media video interface. Signed-off-by: Jean-Francois Moine --- Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt | 14 ++ 1 file changed, 14 insertions(+) diff --git

[PATCH RFC v2 5/6] drm/tilcd: dts: Remove unused slave description

The tda998x being converted to a normal DRM encoder/connector, there is no slave notion anymore. Signed-off-by: Jean-Francois Moine --- Documentation/devicetree/bindings/drm/tilcdc/slave.txt | 18 -- 1 file changed, 18 deletions(-) delete mode 100644

[pci] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_crtc.c:94 drm_warn_on_modeset_not_all_locked()

// CC Stephane for RAPL related bug Bjorn, sorry this bug report is mis-titled. The only new bug that show up in aa11fc58dc is on rapl_pmu_init. And it shows up only 1 time, so it's hard to reproduce and the bisect is likely not accurate. I'll retry the bisect with more repeat count. Sorry for

[PATCH] drm/ttm: remove fence_lock

On Fri, Oct 19, 2012 at 3:04 AM, Jerome Glisse wrote: > On Thu, Oct 18, 2012 at 06:43:40PM +0200, Thomas Hellstrom wrote: >> On 10/18/2012 04:45 PM, Maarten Lankhorst wrote: >> >Op 18-10-12 13:55, Thomas Hellstrom schreef: >> >>On 10/18/2012 01:38 PM, Maarten Lankhorst wrote: >> >>>Op 18-10-12

[PATCH RFC v2 6/6] ARM: AM33XX: dts: Change the tda998x description

The tda998x being moved from a 'slave encoder' to a normal DRM encoder/connector and the tilcdc_slave glue being removed, the declaration of the HDMI transmitter description must be changed in the associated DTs. Signed-off-by: Jean-Francois Moine --- arch/arm/boot/dts/am335x-base0033.dts | 28

[PATCH RFC v2 4/6] drm/tilcdc: Change the interface with the tda998x driver

The tda998x being moved from a 'slave encoder' to a normal DRM encoder/connector, the tilcdc_slave glue is not needed anymore. This patch uses the infrastructure for componentised subsystems for waiting to the tda998x full start and to give it the pointer to the DRM device. Signed-off-by:

[PATCH v2] drm: enable render-nodes by default

On 03/21/2014 08:10 AM, Daniel Vetter wrote: > On Thu, Mar 20, 2014 at 10:13 PM, Rob Clark wrote: Ie. an app that was using the gpu for something secure could simply choose not to if the hw/driver could not guarantee that another process using the gpu could not get access to the

[PATCH] drm/ttm: remove fence_lock

On 03/21/2014 12:55 AM, Dave Airlie wrote: > On Fri, Oct 19, 2012 at 3:04 AM, Jerome Glisse wrote: >> On Thu, Oct 18, 2012 at 06:43:40PM +0200, Thomas Hellstrom wrote: >>> On 10/18/2012 04:45 PM, Maarten Lankhorst wrote: Op 18-10-12 13:55, Thomas Hellstrom schreef: > On 10/18/2012 01:38

more locking fail...

: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/ed52f194/attachment-0001.obj>

more locking fail...

On Fri, Mar 21, 2014 at 1:53 AM, Dave Airlie wrote: > So I've been nice, and fixes the suspend/resume one, but the edid one > looks like a bit more auditing/typing, so I'm leaving it for you to > look at :-) With my two patches from yesterday and your resume patch, what's still missing? Atm I

[PATCH RFC v2 2/6] drm/i2c: tda998x: Move tda998x to a couple encoder/connector

The 'slave encoder' structure of the tda998x driver asks for glue between the DRM driver and the encoder/connector structures. This patch changes the driver to a normal DRM encoder/connector thanks to the infrastructure for componentised subsystems. Signed-off-by: Jean-Francois Moine ---

3.14 radeon regression: radeon is broken (pci bug?)

On Fri, Mar 21, 2014 at 7:41 AM, Alex Deucher wrote: > On Thu, Mar 20, 2014 at 10:17 PM, Andy Lutomirski > wrote: >> My system works on a 3.13 Fedora kernel. It does not work on a >> more-or-less identically configured 3.14-rc7+ kernel. The symptom is >> that the Plymouth password prompt

[PATCH] drm/edid: Fill PAR in AVI infoframe based on CEA mode list

Populate PAR in infoframe structure. If there is a user setting for PAR, then that value is set. Else, value is taken from CEA mode list if VIC is found. Else, PAR is calculated from resolution. If none of these conditions are satisfied, PAR is NONE as per initialization. As a next step, create a

[PATCH v2] drm: enable render-nodes by default

On Thu, Mar 20, 2014 at 10:13 PM, Rob Clark wrote: >>> Ie. an app that was using the gpu for something secure could >>> simply choose not to if the hw/driver could not guarantee that another >>> process using the gpu could not get access to the buffers.. >> >> IMO that should work fine, but we

[PATCH] drm/helper: lock all around force mode restore

On Fri, Mar 21, 2014 at 10:46:59AM +1000, Dave Airlie wrote: > From: Dave Airlie > > Since Daniel documented things with a sledge hammer, we got lots of > nice backtraces in suspend/resume operations, I've check the callers > of this and they all seems safe to me, > > This fixes one set of

How to check the HDMI TMDS clock frequency and DP link symbol clock frequency, on HSW/BDW/VLV?

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

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

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/20140321/c1ff7627/attachment-0001.html>

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

ing and all but one core. -- 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/20140321/b29f49fa/attachment.html>

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

t;http://lists.freedesktop.org/archives/dri-devel/attachments/20140321/6afa323e/attachment-0001.html>

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

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

[Bug 76286] Kernel v3.13 hang during boot now that dpm is enabled for radeon driver - Radeon HD4870

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

[git pull] drm fixes

Hi Linus, Some final few intel fixes, all regressions, all stable cc, and one exynos oops fixer, the biggest is probably the intel display error irqs one, but it seems to fix a few crashes on startup, and one use after free in drm core. Dave. The following changes since commit

[Bug 76382] Mesa Gallium egllog _eglLog

-devel/attachments/20140321/54b6fcca/attachment.html>

[Bug 76382] Mesa Gallium egllog _eglLog

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

[Bug 76382] Mesa Gallium egllog _eglLog

https://bugs.freedesktop.org/show_bug.cgi?id=76382 --- Comment #3 from Chris --- (In reply to comment #2) > Post a build log. I would love to but now it compiles fine. It seems that when you compile and install it first with -gallium -opnvg -xa disabled it compiles and installs. After that if