[RFC PATCH 05/14] ARM: dts: samsung-fimd: add I80 specific properties

Hi YoungJun, On Thursday 17 April 2014 14:33:37 YoungJun Cho wrote: > On 04/17/2014 06:26 AM, Laurent Pinchart wrote: > > On Tuesday 15 April 2014 14:47:33 YoungJun Cho wrote: > >> In case of using CPU interface panel, the relevant registers should be > >> set. So this patch adds relevant dt

[RFC v2 PATCH v2 06/14] drm/exynos: support MIPI DSI command mode

Hi YoungJun, Thank you for the patch. On Monday 21 April 2014 21:28:33 YoungJun Cho wrote: > This patch adds I80 interface for FIMD to support command mode panel. > > For this, the below features are added: > - Sets display interface mode relevant registers properly according to the >

[RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

Hi YoungJun, Thank you for the patch. On Monday 21 April 2014 21:28:37 YoungJun Cho wrote: > This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver. > > Changelog v2: > - Declares delay, size properties in probe routine instead of DT > Changelog v3: > - Moves CPU timings

[Bug 42960] Display does not work when resuming from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=42960 --- Comment #42 from Sandeep --- Compiling, will reply when I have finished testing. I am applying it against 3.15-rc2 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML

[Bug 77751] New: displayport broken, radeon HD 7970 and DELL 3008WFPt

https://bugs.freedesktop.org/show_bug.cgi?id=77751 Priority: medium Bug ID: 77751 Assignee: dri-devel at lists.freedesktop.org Summary: displayport broken, radeon HD 7970 and DELL 3008WFPt Severity: blocker Classification: Unclassified

[PATCH v2 07/10] drm/nouveau/graph: pad firmware code at load time

On Tue, Apr 22, 2014 at 4:03 AM, Ilia Mirkin wrote: > On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot > wrote: >> Pad the microcode to a multiple of 0x40 bytes, otherwise firmware will > > bytes or u32's? From the code, I'm guessing the latter. (Similar > concern about comment in the code.)

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20140422/84532d3c/attachment.html>

[Bug 77751] displayport broken, radeon HD 7970 and DELL 3008WFPt

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/5ea7daf7/attachment.html>

[RFC v2 PATCH v2 06/14] drm/exynos: support MIPI DSI command mode

Hi Laurent, Thank you for the comment. On 04/22/2014 07:52 AM, Laurent Pinchart wrote: > Hi YoungJun, > > Thank you for the patch. > > On Monday 21 April 2014 21:28:33 YoungJun Cho wrote: >> This patch adds I80 interface for FIMD to support command mode panel. >> >> For this, the below features

[RFC v2 PATCH v3 10/14] drm/panel: add S6E3FA0 driver

Hi Laurent, Thank you for the comment. On 04/22/2014 08:00 AM, Laurent Pinchart wrote: > Hi YoungJun, > > Thank you for the patch. > > On Monday 21 April 2014 21:28:37 YoungJun Cho wrote: >> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver. >> >> Changelog v2: >> -

[PATCH V2 1/9] drm/exynos: dp: support hotplug detection via GPIO

From: Andrew Bresticker Certain bridge chips use a GPIO to indicate the cable status instead of the I_DP_HPD pin. This adds an optional device-tree property, "samsung,hpd-gpio", to the exynos-dp controller which indicates that the specified GPIO should be used for hotplug

[PATCH V2 3/9] drm/panel: Add driver for exynos_dp based panels

This patch adds a simple driver to handle all the LCD and LED powerup/down routines needed to support eDP/eDP-LVDS panels supported on exynos boards. The LCD and LED units are usually powered up via regulators, and almost on all boards, we will have a BL_EN pin to enable/ disable the backlight.

[PATCH V2 6/9] drm/bridge: ptn3460: enable polling based detection

From: Rahul Sharma Add DRM_CONNECTOR_POLL_HPD to the set of connector flags while registering drm_connector for ptn3460. Signed-off-by: Rahul Sharma Signed-off-by: Ajay Kumar --- Changes since V1: No Change since V1 drivers/gpu/drm/bridge/ptn3460.c |1 +

[PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

attach ptn3460 connector to drm_panel and support drm_panel routines, if a valid drm_panel object is passed to ptn3460_init. Signed-off-by: Ajay Kumar --- Changes since V1: Address few coding style comments from Jingoo Han drivers/gpu/drm/bridge/Kconfig |1 +

[PATCH V2 2/9] drm/panel: add pre_enable and post_disable routines

Most of the panels need an init sequence as mentioned below: -- poweron LCD unit/LCD_EN -- start video data -- poweron LED unit/BL_EN And, a de-init sequence as mentioned below: -- poweroff LED unit/BL_EN -- stop video data -- poweroff LCD

[PATCH V2 5/9] drm/exynos: dp: modify driver to support drm_panel

This patch attaches the dp connector to exynos_dp_panel, and adds calls to drm_panel functions to control panel power sequence. Signed-off-by: Ajay Kumar --- Changes since V1: Addressed a comment from Jingoo Han. Also added post_disable control to exynos_dp driver.

[PATCH V2 8/9] drm/bridge: Add PS8622 bridge driver

This patch adds a drm_bridge driver for the PS8622 DisplayPort to LVDS bridge chip. Signed-off-by: Andrew Bresticker Signed-off-by: Sean Paul Signed-off-by: Rahul Sharma Signed-off-by: Ajay Kumar --- Changes since V1: Pushing V1 for this as V2 because this patch holds good in this

[PATCH V2 9/9] drm/exynos: Add ps8622 lvds bridge discovery to DP driver

This patch adds ps8622 lvds bridge discovery code to the dp driver. Signed-off-by: Rahul Sharma Signed-off-by: Ajay Kumar --- Changes since V1: Pushing V1 for this as V2 because this patch holds good in this series. drivers/gpu/drm/exynos/exynos_dp_core.c |9 + 1 file

[PATCH V2 0/9] drm: exynos: few patches to enhance bridge chip support

This series is based on exynos-drm-next-todo branch of Inki Dae's tree at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git This set of drm patches are needed to support bridge chips and eDP/LVDS panels with exynos_dp. Bridge chip driver for parade DP to LVDS converter is

[PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver

Register exynos_dp_panel before the list of exynos crtcs and connectors are probed. This is needed because exynos_dp_panel should be registered to the drm_panel list via panel-exynos-dp probe, i.e much before exynos_dp_bind calls of_drm_find_panel(). Signed-off-by: Ajay Kumar --- Changes since

[Nouveau] [PATCH v2 09/10] drm/nouveau: support GK20A in nouveau_accel_init()

On Tue, Apr 22, 2014 at 4:07 AM, Ilia Mirkin wrote: > On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot > wrote: >> Skip the creation of a software channel for GK20A as software methods >> are not yet supported. > > How is GK20A different from a nvc0+ card that lacks PDISPLAY (like all > the

[PATCH v2 07/10] drm/nouveau/graph: pad firmware code at load time

On 04/22/2014 08:48 AM, Ben Skeggs wrote: > On Tue, Apr 22, 2014 at 4:03 AM, Ilia Mirkin wrote: >> On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot >> wrote: >>> Pad the microcode to a multiple of 0x40 bytes, otherwise firmware will >> >> bytes or u32's? From the code, I'm guessing the

[Nouveau] [PATCH v2 09/10] drm/nouveau: support GK20A in nouveau_accel_init()

On 04/22/2014 03:07 AM, Ilia Mirkin wrote: > On Mon, Apr 21, 2014 at 2:02 AM, Alexandre Courbot > wrote: >> Skip the creation of a software channel for GK20A as software methods >> are not yet supported. > > How is GK20A different from a nvc0+ card that lacks PDISPLAY (like all > the 3D

[PATCH] drm/exynos: use %pad for dma_addr_t

Use %pad for dma_addr_t, because a dma_addr_t type can vary based on build options. So, it prevents possible build warnings in printks. Signed-off-by: Jingoo Han --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +- drivers/gpu/drm/exynos/exynos_drm_vidi.c |2 +- 2 files changed, 2

[Bug 77751] displayport broken, radeon HD 7970 and DELL 3008WFPt

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

[PATCH] drm/radeon/aux: fix hpd assignment for aux bus

The hpd (hot plug detect) pin assignment got lost in the conversion to to the common i2c over aux code. Without this information, aux transactions do not work properly. Fixes DP failures. Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/atombios_dp.c | 1 + 1 file changed, 1

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

the problem occurred) and glxinfo. -- 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/20140422/45554995/attachment.html>

[PATCH V2 1/9] drm/exynos: dp: support hotplug detection via GPIO

On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote: > > From: Andrew Bresticker > > Certain bridge chips use a GPIO to indicate the cable status instead > of the I_DP_HPD pin. This adds an optional device-tree property, > "samsung,hpd-gpio", to the exynos-dp controller which indicates that >

[PATCH V2] gpu: host1x: handle the correct # of syncpt regs

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

[PATCH V2 3/9] drm/panel: Add driver for exynos_dp based panels

On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote: > > This patch adds a simple driver to handle all the LCD and LED > powerup/down routines needed to support eDP/eDP-LVDS panels > supported on exynos boards. > > The LCD and LED units are usually powered up via regulators, > and almost on all

[PATCH 1/3] ARM: tegra: Deprecate nvidia,hpd-gpio property

with a patch. 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/20140422/e3b8058c/attachment-0001.sig>

[PATCH 00/18] drm_bus cleanups and other cruft removal

Hi On Fri, Apr 11, 2014 at 11:35 PM, Daniel Vetter wrote: > Hi all, > > I've chatted a bit with Thierry about how we could allow drivers to not even > required a drm_bus any more. Which is relevant when e.g. due to the new > master/component no platform device is conveniently around. > > So

[RFC v2 PATCH v2 06/14] drm/exynos: support MIPI DSI command mode

Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/6fad61ab/attachment.sig>

[PATCH] drm: fix memory leak around mode_group

Hi On Fri, Apr 18, 2014 at 2:02 AM, Dave Airlie wrote: > From: Dave Airlie > > This mode group id_list was never being freed. > > Signed-off-by: Dave Airlie > --- > drivers/gpu/drm/drm_crtc.c | 6 ++ > drivers/gpu/drm/drm_stub.c | 1 + > include/drm/drm_crtc.h | 1 + > 3 files

[Bug 66963] Rv6xx dpm problems

relevant piece of information. -- 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/20140422/f4bc2324/attachment.html>

[PATCH] drm/radeon: Fix num_banks calculation for SI

From: Michel D?nzer The way the tile mode array index was calculated only makes sense for the CIK specific macrotile mode array. For SI, we need to use one of the tile mode array indices reserved for displayable surfaces. This happened to result in correct display most

[PATCH V2 2/9] drm/panel: add pre_enable and post_disable routines

enable() and post_post_disable() function then? There's got to be a better way to solve 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/20140422/ca79d9d0/attachment.sig>

[PATCH] drm/fb-helper: Fix hpd vs. initial config races

On Thu, Apr 17, 2014 at 10:38:17AM +0200, Thierry Reding wrote: > On Wed, Apr 16, 2014 at 04:45:21PM +0200, Daniel Vetter wrote: > > Some drivers need to be able to have a perfect race-free fbcon setup. > > Current drivers only enable hotplug processing after the call to > >

[PATCH V2 3/9] drm/panel: Add driver for exynos_dp based panels

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/20140422/b90c2a3c/attachment.sig>

REGRESSION: OOPS: Intel Corporation Core Processor Integrated Graphics Controller, Linux HEAD when powering off internal Laptop display on t410s and extending and rotating external screen

On Thu, Apr 17, 2014 at 05:06:24PM +0300, Jani Nikula wrote: > On Thu, 17 Apr 2014, Thomas Glanzmann wrote: > > Hello, > > I have t410s with an internal Intel graphic card. I have the > > Laptop display (LVDS1) and an external HP ZR2440W Monitor connected to > > the Display port. I pulled

Warning on resume

On Sun, Apr 20, 2014 at 12:50:23PM -0700, Stephen Hemminger wrote: > I got this on my desktop (Haswell) box when resuming from suspend > with Debian testing kernel (3.13). I've just worked on a massive patch series to rework the haswell WRPLL. It kills the hsw specific shared pll framework and

[PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver

t no longer fits in any kind of memory. 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/20140422/ed48b218/attachment.sig>

[PATCH V2 5/9] drm/exynos: dp: modify driver to support drm_panel

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

[PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

Hi Russel, My answer little bit later due to Easter. On 04/18/2014 02:42 PM, Russell King - ARM Linux wrote: > On Fri, Apr 18, 2014 at 01:27:53PM +0200, Andrzej Hajda wrote: >> Hi Russel, >> >> Thanks for comments. >> >> On 04/17/2014 11:47 PM, Russell King - ARM Linux wrote: >>> On Thu, Apr 17,

[PATCH V2 8/9] drm/bridge: Add PS8622 bridge driver

On Tuesday, April 22, 2014 7:39 AM, Ajay Kumar wrote: > > This patch adds a drm_bridge driver for the PS8622 DisplayPort to LVDS > bridge chip. > > Signed-off-by: Andrew Bresticker > Signed-off-by: Sean Paul > Signed-off-by: Rahul Sharma > Signed-off-by: Ajay Kumar > --- > Changes since V1:

[PATCH V2 6/9] drm/bridge: ptn3460: enable polling based detection

ble Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/6181e9c1/attachment.sig>

[PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

- 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/20140422/a3348d20/attachment.sig>

[PATCH] drm/fb-helper: Fix hpd vs. initial config races

rudimentary initialization. > > Hm yeah I think this should be sufficient, too. It would be good to > extract this minimal initialization into a new drm_fb_helper_prepare > function and update the kerneldoc a bit more. Maybe as a patch on top of > mine? > > Then we could merge this all as an early tegra-next pull to Dave. Sounds like a good idea. I'll go prepare a patch. 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/20140422/29d75edf/attachment.sig>

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

The introduction of primary planes has apparently caused a bit of fb refcounting fun for people. That makes it a good time to clean up the arcane rules and slight differences between ->update_plane and ->set_config. The new rules are: - The core holds a reference for both the new and the old fb

Design review request: DRM color manager

Gentle reminder Regards Shashank -Original Message- From: Sharma, Shashank Sent: Friday, April 18, 2014 12:01 PM To: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; Ville Syrj?l?; Thierry Reding; Alex Deucher; Sean Paul; robdclark at gmail.com Cc: Shankar, Uma;

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

d-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/20140422/bbdd43b3/attachment.sig>

[PATCH] drm/radeon/aux: fix hpd assignment for aux bus

Am 22.04.2014 08:02, schrieb Alex Deucher: > The hpd (hot plug detect) pin assignment got lost > in the conversion to to the common i2c over aux > code. Without this information, aux transactions > do not work properly. Fixes DP failures. > > Signed-off-by: Alex Deucher Added to my 3.15 queue.

[PATCH V2 9/9] drm/exynos: Add ps8622 lvds bridge discovery to DP driver

doesn't have to know that kind of detail. 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/20140422/cd96a7aa/attachment.sig>

Design review request: DRM color manager

Hi On Tue, Apr 22, 2014 at 6:11 AM, Sharma, Shashank wrote: > Gentle reminder Usual approach is to send any proposals as inline plain-text. It's really hard to comment on attachments, especially if it's an MS-office format. Anyhow, some comments on the proposal: 1) Why do you register only a

[PATCH 10/18] drm/irq: track the irq installed in drm_irq_install in dev->irq

On Thu, Apr 17, 2014 at 12:02:07AM +0200, Laurent Pinchart wrote: > And another comment... > > On Friday 11 April 2014 23:36:07 Daniel Vetter wrote: > > To get rid of the dev->bus->get_irq callback we need to pass in the > > desired irq explicitly into drm_irq_install. To avoid having to do the >

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

On Tue, Apr 22, 2014 at 11:07:13AM +0200, Daniel Vetter wrote: > The introduction of primary planes has apparently caused a bit of fb > refcounting fun for people. That makes it a good time to clean up the > arcane rules and slight differences between ->update_plane and > ->set_config. The new

[PATCH] drm/fb-helper: Fix hpd vs. initial config races

void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper, const struct drm_fb_helper_funcs *funcs) { helper->funcs = funcs; helper->dev = dev; } So I wonder if that's still what we want or whether drivers should simply be doing that manually if they need to. Having a function for it gives us a place to document things, though, and perhaps at some point we'll have to extend this, so it may be a good idea after all, even if it's just the two lines currently. 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/20140422/b398c072/attachment.sig>

[PATCH v2 04/10] drm/nouveau/fb: add GK20A support

836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140422/bc54b184/attachment.sig>

[PATCH 10/18] drm/irq: track the irq installed in drm_irq_install in dev->irq

buse already. > > In any case this should be a separate patch. I agree. This patch mostly mechanically replaces things and this bug did already exist previously. So let's fix it separately (if at all). 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/20140422/45302ad3/attachment.sig>

[PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote: > On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote: >> Separation of the interfaces exposed by the device from the device itself >> seems to me a good thing. I would even consider it as a biggest >> advantage of this solution :)

[PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

So what about, rather than adding drm_panel support to each bridge individually, we introduce a drm_panel_bridge (with a form of chaining).. ie: struct drm_panel_bridge { struct drm_bridge base; struct drm_panel *panel; struct drm_bridge *bridge; /* optional */ }; static void

Design review request: DRM color manager

Hi On Tue, Apr 22, 2014 at 12:21 PM, Sharma, Shashank wrote: > 1) Why do you register only a single property? Why not register a separate > property for each color-correction that is available? This way you can drop > the property-id and use the high-level DRM-prop IDs/names. >>> That?s the

[PATCH] drm/fb-helper: Fix hpd vs. initial config races

On Tue, Apr 22, 2014 at 12:08 PM, Thierry Reding wrote: > void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper > *helper, >const struct drm_fb_helper_funcs *funcs) > { > helper->funcs = funcs; > helper->dev = dev; > } > > So I wonder

[PATCH RFC 3/3] drm/exynos: use pending_components for components tracking

On Tue, Apr 22, 2014 at 01:29:54PM +0200, Andrzej Hajda wrote: > On 04/18/2014 02:46 PM, Russell King - ARM Linux wrote: > > On Fri, Apr 18, 2014 at 02:02:37PM +0200, Andrzej Hajda wrote: > >> Separation of the interfaces exposed by the device from the device itself > >> seems to me a good thing.

[PATCH 0/6] File Sealing & memfd_create()

Hi On Tue, Apr 22, 2014 at 11:10 AM, Florian Weimer wrote: > Ah. What do you recommend for recipient to recognize such descriptors? > Would they just try to seal them and reject them if this fails? This highly depends on your use-case. Please see the initial email in this thread. It describes

[PATCH] drm/radeon/aux: fix hpd assignment for aux bus

> -Original Message- > From: Christian K?nig [mailto:deathsimple at vodafone.de] > Sent: Tuesday, April 22, 2014 5:17 AM > To: Alex Deucher; dri-devel at lists.freedesktop.org > Cc: Deucher, Alexander > Subject: Re: [PATCH] drm/radeon/aux: fix hpd assignment for aux bus > > Am 22.04.2014

[RFC v2 PATCH 02/14] drm/exynos: dsi: delay setting clocks after reset

Hi YoungJun, On 04/21/2014 02:28 PM, YoungJun Cho wrote: > Some phy control registers are not kept after software reset. > So this patch makes the clocks containing phy control to be set > after software reset. > > Signed-off-by: YoungJun Cho > Acked-by: Inki Dae > Acked-by: Kyungmin Park >

[PATCH] drm/radeon: fix count in cik_sdma_ring_test()

Should be 5 rather than 4. Noticed-by: Mathias Fr?hlich Signed-off-by: Alex Deucher Cc: stable at vger.kernel.org --- drivers/gpu/drm/radeon/cik_sdma.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/cik_sdma.c b/drivers/gpu/drm/radeon/cik_sdma.c

[PATCH] drm/radeon: Fix num_banks calculation for SI

On Tue, Apr 22, 2014 at 3:53 AM, Michel D?nzer wrote: > From: Michel D?nzer > > The way the tile mode array index was calculated only makes sense for > the CIK specific macrotile mode array. For SI, we need to use one of the > tile mode array indices reserved for displayable surfaces. > > This

[PATCH 0/6] File Sealing & memfd_create()

Hi On Tue, Apr 22, 2014 at 2:44 PM, Florian Weimer wrote: > I didn't find that very convincing. But in v2, seals are monotonic, so > checking them should be reliable enough. Ok. > What happens when you create a loop device on a write-sealed descriptor? Any write-back to the loop-device will

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

On Tue, Apr 22, 2014 at 12:07:41PM +, Sharma, Shashank wrote: > Thanks again David, > Comments inline. Three things: - Please don't send out .pptx files to upstream/public mailing lists, that's just not how the upstream community works. - Please either fix up ms outlook to do proper

[PATCH V2 7/9] drm/bridge: ptn3460: add drm_panel controls

On Tue, Apr 22, 2014 at 07:34:03AM -0400, Rob Clark wrote: > So what about, rather than adding drm_panel support to each bridge > individually, we introduce a drm_panel_bridge (with a form of > chaining).. ie: > > struct drm_panel_bridge { > struct drm_bridge base; > struct drm_panel

[RFC v2 PATCH v4 09/14] ARM: dts: s6e3fa0: add DT bindings

On 04/21/2014 02:28 PM, YoungJun Cho wrote: > This patch adds DT bindings for s6e3fa0 panel. > The bindings describes panel resources, display timings and cpu timings. > > Changelog v2: > - Adds unit address (commented by Sachin Kamat) > Changelog v3: > - Removes optional delay, size properties

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

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

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

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

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

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

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

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

[Bug 77745] [r600g] Call of Duty 4 crashes under Wine due to running out of memory

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

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

On Tue, Apr 22, 2014 at 01:06:22PM +0300, Ville Syrj?l? wrote: > On Tue, Apr 22, 2014 at 11:07:13AM +0200, Daniel Vetter wrote: > > The introduction of primary planes has apparently caused a bit of fb > > refcounting fun for people. That makes it a good time to clean up the > > arcane rules and

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

The introduction of primary planes has apparently caused a bit of fb refcounting fun for people. That makes it a good time to clean up the arcane rules and slight differences between ->update_plane and ->set_config. The new rules are: - The core holds a reference for both the new and the old fb

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

On Tue, Apr 22, 2014 at 04:09:09PM +0200, Daniel Vetter wrote: > On Tue, Apr 22, 2014 at 01:06:22PM +0300, Ville Syrj?l? wrote: > > On Tue, Apr 22, 2014 at 11:07:13AM +0200, Daniel Vetter wrote: > > > The introduction of primary planes has apparently caused a bit of fb > > > refcounting fun for

[PATCH] drm/radeon: fix count in cik_sdma_ring_test()

Am 22.04.2014 14:17, schrieb Alex Deucher: > Should be 5 rather than 4. > > Noticed-by: Mathias Fr?hlich > Signed-off-by: Alex Deucher > Cc: stable at vger.kernel.org Added to my 3.15 queue. Christian. > --- > drivers/gpu/drm/radeon/cik_sdma.c | 2 +- > 1 file changed, 1 insertion(+), 1

[PATCH] drm: Simplify fb refcounting rules around ->update_plane

On Tue, Apr 22, 2014 at 4:28 PM, Ville Syrj?l? wrote: >> Not sure what to do here really. > > Just s/drm_gem_object_unreference_unlocked/drm_gem_object_unreference/ > and grab struct_mutex by hand around both operations? I was kinda hoping for someone to go ahead and fix the entire fb tracking

[PATCH 1/4] drm/fb-helper: Fix hpd vs. initial config races

From: Daniel Vetter Some drivers need to be able to have a perfect race-free fbcon setup. Current drivers only enable hotplug processing after the call to drm_fb_helper_initial_config which leaves a tiny but important race. This race is especially noticable on embedded

[PATCH 2/4] drm: Constify struct drm_fb_helper_funcs

From: Thierry Reding There's no need for this to be modifiable. Make it const so that it can be put into the .rodata section. Signed-off-by: Thierry Reding --- drivers/gpu/drm/armada/armada_fbdev.c | 2 +- drivers/gpu/drm/ast/ast_fb.c | 2 +-

[PATCH 4/4] drm/tegra: Implement race-free hotplug detection

From: Thierry Reding A race condition currently exists on Tegra, where it can happen that a monitor attached via HDMI isn't detected during the initial FB helper setup, but the hotplug event happens too early to be processed by the poll helpers because they haven't been

[PATCH 3/4] drm: Introduce drm_fb_helper_prepare()

From: Thierry Reding To implement hotplug detection in a race-free manner, drivers must call drm_kms_helper_poll_init() before hotplug events can be triggered. Such events can be triggered right after any of the encoders or connectors are initialized. At the same time, if the

[PATCH 1/4] drm/radeon: properly unregister hwmon interface (v2)

Am 15.04.2014 18:44, schrieb Alex Deucher: > Need to properly unregister the hwmon device on driver > unload. > > v2: minor clean up > > bug: > https://bugzilla.kernel.org/show_bug.cgi?id=73931 > > Signed-off-by: Alex Deucher > Cc: stable at vger.kernel.org Added to my 3.15 queue. Sorry for the

[Bug 77009] 24P playback video signal loss with latest DRI patches

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/20140422/c1b91c86/attachment.html>

[RFC 0/5] drm/tegra: Convert to master/component framework

From: Thierry Reding Hi, This series converts the Tegra DRM driver to the master/component framework. The length of the series and the list of people in Cc is mostly due to the fact that Tegra has some special requirements as opposed to other drivers and therefore requires

[RFC 1/5] drivers/base: Allow multiple masters per device

From: Thierry Reding Currently the component/master framework allows only a single master to be registered against a struct device. A master is uniquely identified by the device and the master operations table, but the current API does not pass enough information along to

[RFC 2/5] drivers/base: Allow driver-data to be attached to a master

From: Thierry Reding Similarly to what can be done for device drivers, allow driver-specific data to be attached to a master. This is necessary for masters whose device is already bound to by a different driver and therefore cannot be used to store the driver-specific data.

[RFC 3/5] drivers/base: Add interface framework

From: Thierry Reding Some drivers, such as graphics drivers in the DRM subsystem, do not have a real device that they can bind to. They are often composed of several devices, each having their own driver. The master/component framework can be used in these situations to

[RFC 4/5] drm: Introduce drm_set_unique()

From: Thierry Reding Add a helper function that allows drivers to statically set the unique name of the device. This will allow platform and USB drivers to get rid of their DRM bus implementations and directly use drm_dev_alloc() and drm_dev_register(). Signed-off-by:

[RFC 5/5] drm/tegra: Convert to master/component framework

From: Thierry Reding Instead of the current implementation, reuse the recently introduced master/component framework, which is equivalent in most regards. One issue is that there is no device to bind the DRM driver to. In order to still allow the driver to be probed, expose

[PATCH V2 3/9] drm/panel: Add driver for exynos_dp based panels

isn't specific to one SoC. And the name doesn't imply that either. Also each panel is still identified by the specific compatible value, which makes it easier to find out which driver supports the 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/20140422/a60d37de/attachment.sig>

[PATCH] modetest: add cursor support

From: Rob Clark Signed-off-by: Rob Clark --- Note: I move the position of the getchar() at the end, so we don't stop the cursor test immediately if not testing w/ vblank sync flipping. The previous position of the getchar() seemed to make no sense, but please let me

[PATCH V2 4/9] drm/exynos: add exynos_dp_panel driver registration to drm driver

er doesn't matter one bit. It may happen to work most of the time, but as soon as one of the resources that your panel driver needs isn't there when the panel is probed, then it won't be registered and of_drm_find_panel() will still return NULL. Usually the right thing to do in that case would be to return (and propagate) -EPROBE_DEFER so that your driver's probe is deferred and retried when other drivers have been probed. That way it should eventually get a non-NULL 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/20140422/392c4797/attachment.sig>

[PATCH 2/4] drm: Constify struct drm_fb_helper_funcs

On Tue, Apr 22, 2014 at 04:42:19PM +0200, Thierry Reding wrote: > From: Thierry Reding > > There's no need for this to be modifiable. Make it const so that it can > be put into the .rodata section. > > Signed-off-by: Thierry Reding Reviewed-by: Daniel Vetter > --- >

[RFC 4/5] drm: Introduce drm_set_unique()

On Tue, Apr 22, 2014 at 05:09:32PM +0200, Thierry Reding wrote: > From: Thierry Reding > > Add a helper function that allows drivers to statically set the unique > name of the device. This will allow platform and USB drivers to get rid > of their DRM bus implementations and directly use

  1   2   >