[PATCH] drm: allocate crtc mutex separately from crtc

(dropping stable at ... until we get the fix we can agree on) While looking through that function (drm_crtc_helper_set_config) to figure out what we really need to save and restore, I came across a piece of code that you added in 25f397a4. The 'if (connector->dpms != DRM_MODE_DPMS_ON)' (line 719

[PATCH 5/5] DRM: Armada: add support for drm tda19988 driver

On Tue, Oct 8, 2013 at 11:34 AM, Jean-Francois Moine wrote: > On Tue, 8 Oct 2013 10:49:39 +0100 > Russell King - ARM Linux wrote: > >> On Tue, Oct 08, 2013 at 11:19:13AM +0200, Jean-Francois Moine wrote: >> > The Cubox is an open platform, and I use it just like a desktop PC. >> > When its

[Bug 70439] Mobility 4570: System freezes after ~5s of enabling audio via xrandr

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

[PATCH 4/5] DRM: Armada: start of MMP2/MMP3 support

On Sun, Oct 6, 2013 at 6:10 PM, Russell King wrote: > Signed-off-by: Russell King > --- > drivers/gpu/drm/armada/Makefile |1 + > drivers/gpu/drm/armada/armada_610.c | 49 > ++ >

[PATCH 3/5] DRM: Armada: Add support for ARGB 32x64 or 64x32 hardware cursors

On Mon, Oct 7, 2013 at 8:50 AM, Russell King - ARM Linux wrote: > On Mon, Oct 07, 2013 at 03:29:15PM +0300, Siarhei Siamashka wrote: >> On Mon, 7 Oct 2013 11:32:50 +0100 >> Russell King - ARM Linux wrote: >> > However, what you're suggesting is dangerous. What do you do when you're >> >

[Patch v2][ 14/37] staging: imx-drm: parallel display: add regulator support.

On Thu, Oct 17, 2013 at 05:02:12PM +0200, Denis Carikli wrote: > + if (imxpd->lcd_reg) > + if (regulator_enable(imxpd->lcd_reg)) > + dev_err(imxpd->dev, "Failed to enable lcd > regulator.\n"); > + In staging the style is to use braces around multi-line indents

MmioTrace: Using the Instruction Decoder, etc.

On Mon, 14 Oct 2013 22:45:09 +0400 Eugene Shatokhin wrote: > Hi, > > There is an interesting TODO item on MmioTraceDeveloper page: > "kprobes has a generic instruction decoding facility, use that instead of > homebrewn (or KVM), and use emulation instead of page faulting" > > Actually, I have

[PATCH 4/4] drm/i915: Make the debugfs structures const

Signed-off-by: Damien Lespiau --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index ebbb50e..7dac943 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++

[PATCH 3/4] drm: Make drm_debugfs_list const

Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_debugfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c index 4813ff1..b4b51d4 100644 --- a/drivers/gpu/drm/drm_debugfs.c +++ b/drivers/gpu/drm/drm_debugfs.c

[PATCH 2/4] drm: Remove drm_debugfs_node and drm_debugfs_list

Those structures are not used anywhere. Signed-off-by: Damien Lespiau --- include/drm/drmP.h | 21 - 1 file changed, 21 deletions(-) diff --git a/include/drm/drmP.h b/include/drm/drmP.h index c3b659a..1c502ff 100644 --- a/include/drm/drmP.h +++ b/include/drm/drmP.h @@

[PATCH 1/4] drm: Constify struct drm_info_list * arguments

Those functions are just reading data from those pointers. Signed-off-by: Damien Lespiau --- drivers/gpu/drm/drm_debugfs.c | 4 ++-- include/drm/drmP.h| 9 + 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/drm_debugfs.c

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

> -Original Message- > From: Sean Paul [mailto:seanpaul at chromium.org] > Sent: Thursday, October 17, 2013 4:27 AM > To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com > Cc: airlied at linux.ie; tomasz.figa at gmail.com; marcheu at chromium.org; > Sean > Paul > Subject:

[Patch v2][ 14/37] staging: imx-drm: parallel display: add regulator support.

Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Stephen Warren Cc: Ian Campbell Cc: devicetree at vger.kernel.org Cc: Greg Kroah-Hartman Cc: driverdev-devel at linuxdriverproject.org Cc: David Airlie Cc: dri-devel at lists.freedesktop.org Cc: Sascha

[Patch v2][ 13/37] staging: imx-drm: Add RGB666 support for parallel display

Support the RGB666 format on the IPUv3 parallel display. Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Stephen Warren Cc: Ian Campbell Cc: devicetree at vger.kernel.org Cc: Greg Kroah-Hartman Cc: driverdev-devel at linuxdriverproject.org Cc: David

[Patch v2][ 12/37] staging: imx-drm: ipuv3-crtc: don't harcode some mode flags.

This change is needed for making the eukrea-cpuimx51 QVGA display work. Greg Kroah-Hartman Cc: driverdev-devel at linuxdriverproject.org Cc: Philipp Zabel Cc: Sascha Hauer Cc: linux-arm-kernel at lists.infradead.org Cc: David Airlie Cc: dri-devel at lists.freedesktop.org Cc: Eric B?nard

[Patch v2][ 11/37] staging: imx-drm: use of_get_display_timings.

The comment on top of of_get_drm_display_mode says: * This function is expensive and should only be used, if only one mode is to be * read from DT. To get multiple modes start with of_get_display_timings and * work with that instead. Cc: Greg Kroah-Hartman Cc: driverdev-devel at

[Patch v2][ 04/37] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.

That new macro is needed by the imx_drm staging driver for supporting the QVGA display of the eukrea-cpuimx51 board. Cc: Rob Herring Cc: Pawel Moll Cc: Mark Rutland Cc: Stephen Warren Cc: Ian Campbell Cc: devicetree at vger.kernel.org Cc: Greg

[Patch v2][ 03/37] drm: Add the lacking DRM_MODE_FLAG_* for matching the DISPLAY_FLAGS_*

Without that fix, drivers using the drm_display_mode_from_videomode function will not be able to get certain information because some DISPLAY_FLAGS_* have no corresponding DRM_MODE_FLAG_*. Cc: Greg Kroah-Hartman Cc: driverdev-devel at linuxdriverproject.org Cc: David Airlie Cc: dri-devel at

[PATCH 2/2] drm/radeon: rework audio option

In 3.12 I changed audio to be enabled by default, but you still had to turn it on via xrandr. This was confusing to users so change it to minic the previous behavior: - audio option is set to -1 (auto) by default which is the current 3.12 behavior (audio is enabled but requires xrandr to

[PATCH 1/2] drm/radeon/audio: don't set speaker allocation on DCE3.2

It causes hangs on some asics. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=70439 Signed-off-by: Alex Deucher --- drivers/gpu/drm/radeon/r600_hdmi.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c b/drivers/gpu/drm/radeon/r600_hdmi.c index

[PATCH/RFC v3 00/19] Common Display Framework

n if in practice both APIs are used by the same driver, and the driver can manage the locking, that's not really a valid requirement. It'd be almost the same as requiring that gpio API cannot be called at the same time as i2c API. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/034cfbd6/attachment-0001.pgp>

[RFR 2/2] drm/panel: Add simple panel support

can be made optional. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/bed122fd/attachment-0001.pgp>

[Bug 68391] [radeonsi] Crash unigine-sanctuary

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

[RFR 2/2] drm/panel: Add simple panel support

--- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/2ac17d35/attachment-0001.pgp>

[RFR 2/2] drm/panel: Add simple panel support

panel (possibly with a direction). What > I'd > like to do is to express that link in a way that can also express more > complex > pipeline topologies. I don't want to make it overly complex, I had hoped that > my DT bindings proposal would be a good approach as it's both generic and > still pretty simple. I get that, and for what it's worth I do think that your proposal looks simple enough and if it can solve any of the problem you're facing with CDF, then that's great. But I don't think we should force inclusion of these properties on every panel, even if it doesn't use any of the graph functionality. Is there any problem with making them optional? 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/20131017/c1a7e062/attachment.pgp>

[RFR 2/2] drm/panel: Add simple panel support

bbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/d0388027/attachment-0001.pgp>

[RFR 2/2] drm/panel: Add simple panel support

comes necessary. > > > > > > I share Tomi's point of view here. Your three panels use the same power > > > sequence, so I believe we should have a generic panel compatible string > > > that would use modes described in DT for the common case. Only if a panel >

[PATCH 2/8] [media] exynos4-is: Don't use i2c_client->driver

Em Sun, 29 Sep 2013 10:51:00 +0200 Lars-Peter Clausen escreveu: > The 'driver' field of the i2c_client struct is redundant and is going to be > removed. The results of the expressions 'client->driver.driver->field' and > 'client->dev.driver->field' are identical, so replace all occurrences of

[PATCH 3/8] [media] core: Don't use i2c_client->driver

Em Sun, 29 Sep 2013 10:51:01 +0200 Lars-Peter Clausen escreveu: > The 'driver' field of the i2c_client struct is redundant and is going to be > removed. The results of the expressions 'client->driver.driver->field' and > 'client->dev.driver->field' are identical, so replace all occurrences of

[PATCH] drm: Pad drm_mode_get_connector to 64-bit boundary

> > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 828 bytes Desc: This is a digitally signed message part URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/381036d4/attachment.pgp>

[RFR 2/2] drm/panel: Add simple panel support

ideo-property = ; }; The above would imply one port and one endpoint. Would that work? If we had a function like parse_endpoint(node), we could just point it to either a real endpoint node, or to the device's node. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/deedefa3/attachment-0001.pgp>

[PATCH/RFC v3 00/19] Common Display Framework

On 10/17/2013 10:18 AM, Tomi Valkeinen wrote: > On 17/10/13 10:48, Andrzej Hajda wrote: > >> The main function of DSI is to transport pixels from one IP to another IP >> and this function IMO should not be modeled by display entity. >> "Power, clocks, etc" will be performed via control bus

[RFR 2/2] drm/panel: Add simple panel support

quot;, "generic-panel"; > > > > > > > > and if there's no need for any power/gpio setup for your board, you > > > > may skip adding "foo,specific-panel" support to the panel driver. > > > > Later, somebody else may need to implement fine grained power/gpio > > > > support for "foo,specific-panel", and it would just work. > > > > > > > > Maybe that would help us with the problem of adding support in the > > > > driver for a hundred different simple panels each used only once on a > > > > specific board. > > > > > > Sure, that all sounds like reasonable additions. All of the suggestions > > > are even backwards-compatible and hence can be added when needed without > > > breaking compatibility with existing users of the binding. > > > > What's wrong with moving the three hardcoded modes we already have in the > > driver to DT before pushing this to mainline ? > > I think I've answered that in a different subthread. Then I might not have understood your answer :-) -- Regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/92a72d44/attachment.pgp>

[RFR 2/2] drm/panel: Add simple panel support

.. Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/3a8c2808/attachment.pgp>

[RFR 2/2] drm/panel: Add simple panel support

he driver for that panel. Otherwise we'll have to keep adding > > > the same mode timings for every board that uses the same panel. > > > > > > I do agree though that it might be useful to tweak the mode in case the > > > default one doesn't work. How about we provide a means to override the > > > mode encoded in the driver using one specified in the DT? That's > > > obviously a backwards-compatible change, so it could be added if or when > > > it becomes necessary. > > > > I share Tomi's point of view here. Your three panels use the same power > > sequence, so I believe we should have a generic panel compatible string > > that would use modes described in DT for the common case. Only if a panel > > required something more complex which can't (or which could, but won't > > for any reason) accurately be described in DT would you need to extend > > the driver. > > I don't see the point quite frankly. You seem to be assuming that every > panel will only be used in a single board. No, but in practice that's often the case, at least for boards with .dts files in the mainline kernel. > However what you're proposing will require the mode timings to be repeated > in every board's DT file, if the same panel is ever used on more than a > single board. Is that a problem ? You could #include a .dtsi for the panel that would specify the video mode if you want to avoid multiple copies. -- Regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/711c8eee/attachment-0001.pgp>

[RFR 2/2] drm/panel: Add simple panel support

still the DSI _control_ler that _control_s the panel. There's no electrical way that the panel can take possession of the bus. Well, there's BTA, but even that happens under supervision of the DSI controller. 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/20131017/395325d5/attachment-0001.pgp>

[PATCH v2 26/26] drm/exynos: Consolidate suspend/resume in drm_drv

> -Original Message- > From: Sean Paul [mailto:seanpaul at chromium.org] > Sent: Thursday, October 17, 2013 5:40 AM > To: dri-devel; InKi Dae > Cc: Dave Airlie; Tomasz Figa; St?phane Marchesin; Sean Paul > Subject: Re: [PATCH v2 26/26] drm/exynos: Consolidate suspend/resume in > drm_drv

[RFR 2/2] drm/panel: Add simple panel support

ater, > > > somebody else may need to implement fine grained power/gpio support for > > > "foo,specific-panel", and it would just work. > > > > > > Maybe that would help us with the problem of adding support in the > > > driver for a hundred different simple panels each used only once on a > > > specific board. > > > > Sure, that all sounds like reasonable additions. All of the suggestions > > are even backwards-compatible and hence can be added when needed without > > breaking compatibility with existing users of the binding. > > What's wrong with moving the three hardcoded modes we already have in the > driver to DT before pushing this to mainline ? I think I've answered that in a different subthread. 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/20131017/63a1008f/attachment.pgp>

[PATCH 0/7] drm: Return -ENOENT when objects can't be found

On Thu, Oct 17, 2013 at 12:34 PM, wrote: > We're rather inconsistent in which error values we return to userspace > on failure. I want to unify the behaviour a bit and consistently return > ENOENT when mode object lookups fail. We already do that in a few places > but in most places we just

[RFR 2/2] drm/panel: Add simple panel support

d imply one port and one endpoint. Would that work? If we > had a function like parse_endpoint(node), we could just point it to > either a real endpoint node, or to the device's node. You reference the display controller here, not a specific display controller output. Don't most display controllers have several outputs ? -- Regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/2584b329/attachment.pgp>

[RFR 2/2] drm/panel: Add simple panel support

comes necessary. > > I share Tomi's point of view here. Your three panels use the same power > sequence, so I believe we should have a generic panel compatible string that > would use modes described in DT for the common case. Only if a panel required > something more complex which can't (or which could, but won't for any reason) > accurately be described in DT would you need to extend the driver. I don't see the point quite frankly. You seem to be assuming that every panel will only be used in a single board. However what you're proposing will require the mode timings to be repeated in every board's DT file, if the same panel is ever used on more than a single board. 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/20131017/24f979e8/attachment.pgp>

[PATCH 7/7] drm/vmwgfx: Return -ENOENT when a framebuffer can't be found

From: Ville Syrj?l? Let's be a bit more consistent with our error values. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c

[PATCH 6/7] drm/vmwgfx: Return -ENOENT when a mode object can't be found

From: Ville Syrj?l? Let's be a bit more consistent with our error values. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c

[PATCH 5/7] drm/radeon: Return -ENOENT when a mode object can't be found

From: Ville Syrj?l? Let's be a bit more consistent with our error values. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/radeon/r100.c| 2 +- drivers/gpu/drm/radeon/r600_cs.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 4/7] drm/i915: Return -ENOENT when a mode object can't be found

From: Ville Syrj?l? Let's be a bit more consistent with our error values. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/i915/intel_display.c | 2 +- drivers/gpu/drm/i915/intel_sprite.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git

[PATCH 3/7] drm/gma500: Return -ENOENT when a mode object can't be found

From: Ville Syrj?l? Let's be a bit more consistent with our error values. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/gma500/psb_drv.c | 4 ++-- drivers/gpu/drm/gma500/psb_intel_display.c | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)

[PATCH 2/7] drm: Return -ENOENT when a framebuffer can't be found

From: Ville Syrj?l? Return -ENOENT for framebuffers like we do for other mode objects that can't be found. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git

[PATCH 1/7] drm: Consistently return -ENOENT when a mode object can't be found

From: Ville Syrj?l? We tend to return -EINVAL for everything. Let's try to help poor userland developers a bit by at least returning -ENONET for missing objects. Signed-off-by: Ville Syrj?l? --- drivers/gpu/drm/drm_crtc.c | 32 ++-- 1

[PATCH 0/7] drm: Return -ENOENT when objects can't be found

We're rather inconsistent in which error values we return to userspace on failure. I want to unify the behaviour a bit and consistently return ENOENT when mode object lookups fail. We already do that in a few places but in most places we just return EINVAL. I made a separate patch for each

[PATCH] drm: never write to the userspace more data than the caller wants

On Wed, Oct 16, 2013 at 08:12:35PM -0400, Pavel Roskin wrote: > The amount of data wanted by the userspace caller is encoded in the > ioctl number. Generic drm ioctls were ignoring it. > > As a result, Intel Xorg driver didn't work for i386 userspace on x86_64 > kernel on some systems.

[RFR 2/2] drm/panel: Add simple panel support

, you may skip adding "foo,specific-panel" support to the panel driver. Later, somebody else may need to implement fine grained power/gpio support for "foo,specific-panel", and it would just work. Maybe that would help us with the problem of adding support in the driver for a hundre

[RFR 2/2] drm/panel: Add simple panel support

may > > skip adding "foo,specific-panel" support to the panel driver. Later, > > somebody else may need to implement fine grained power/gpio support for > > "foo,specific-panel", and it would just work. > > > > Maybe that would help us with the problem of adding support in the > > driver for a hundred different simple panels each used only once on a > > specific board. > > Sure, that all sounds like reasonable additions. All of the suggestions > are even backwards-compatible and hence can be added when needed without > breaking compatibility with existing users of the binding. What's wrong with moving the three hardcoded modes we already have in the driver to DT before pushing this to mainline ? -- Regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/9868ff44/attachment.pgp>

[RFR 2/2] drm/panel: Add simple panel support

wer/gpio setup for your board, you may > skip adding "foo,specific-panel" support to the panel driver. Later, > somebody else may need to implement fine grained power/gpio support for > "foo,specific-panel", and it would just work. > > Maybe that would help us with the problem of adding support in the > driver for a hundred different simple panels each used only once on a > specific board. Sure, that all sounds like reasonable additions. All of the suggestions are even backwards-compatible and hence can be added when needed without breaking compatibility with existing users of the binding. 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/20131017/c685f2e2/attachment-0001.pgp>

[RFR 2/2] drm/panel: Add simple panel support

within the driver. And when we already have the panel model > encoded in the compatible value, we might just as well encode the mode > within the driver for that panel. Otherwise we'll have to keep adding > the same mode timings for every board that uses the same panel. > > I do agree though that it might be useful to tweak the mode in case the > default one doesn't work. How about we provide a means to override the > mode encoded in the driver using one specified in the DT? That's > obviously a backwards-compatible change, so it could be added if or when > it becomes necessary. I share Tomi's point of view here. Your three panels use the same power sequence, so I believe we should have a generic panel compatible string that would use modes described in DT for the common case. Only if a panel required something more complex which can't (or which could, but won't for any reason) accurately be described in DT would you need to extend the driver. -- Regards, Laurent Pinchart -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part. URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/ac2224f4/attachment.pgp>

[Bug 68391] [radeonsi] Crash unigine-sanctuary

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

[PATCH/RFC v3 00/19] Common Display Framework

at all the extra complexity brought with separating the control to a separate bus is not worth it. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 901 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/578545c6/attachment-0001.pgp>

[PATCH] drm: never write to the userspace more data than the caller wants

On Thu, 17 Oct 2013 13:26:47 +0100 Chris Wilson wrote: > On Wed, Oct 16, 2013 at 08:12:35PM -0400, Pavel Roskin wrote: > > The amount of data wanted by the userspace caller is encoded in the > > ioctl number. Generic drm ioctls were ignoring it. > > > > As a result, Intel Xorg driver didn't

[RFR 2/2] drm/panel: Add simple panel support

updated for every new simple panel model (and we know there are lots of > them), > why don't you specify the modes in the panel DT node ? The simple panel > driver > would then become much more generic. It would also allow board designers to > tweak h/v sync timings depending on the system requirements. Sigh... we keep second-guessing ourselves. Back at the time when power sequences were designed (and NAKed at the last minute), we all decided that the right thing to do would be to use specific compatible values for individual panels, because that would allow us to encode the power sequencing within the driver. And when we already have the panel model encoded in the compatible value, we might just as well encode the mode within the driver for that panel. Otherwise we'll have to keep adding the same mode timings for every board that uses the same panel. I do agree though that it might be useful to tweak the mode in case the default one doesn't work. How about we provide a means to override the mode encoded in the driver using one specified in the DT? That's obviously a backwards-compatible change, so it could be added if or when it becomes necessary. 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/20131017/45b2d0c3/attachment-0001.pgp>

[PATCH v2 12/26] drm/exynos: Split manager/display/subdrv

On Thu, Oct 17, 2013 at 4:21 AM, Inki Dae wrote: > > >> -Original Message- >> From: Sean Paul [mailto:seanpaul at chromium.org] >> Sent: Thursday, October 17, 2013 4:27 AM >> To: dri-devel at lists.freedesktop.org; inki.dae at samsung.com >> Cc: airlied at linux.ie; tomasz.figa at

[PATCH 1/7] drm: Consistently return -ENOENT when a mode object can't be found

On Thu, Oct 17, 2013 at 6:35 AM, wrote: > From: Ville Syrj?l? > > We tend to return -EINVAL for everything. Let's try to help poor > userland developers a bit by at least returning -ENONET for missing > objects. > > Signed-off-by: Ville Syrj?l? For the series: Reviewed-by: Alex Deucher >

[Bug 68391] [radeonsi] Crash unigine-sanctuary

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

[Bug 70569] DOTA2 background and other missing elements on HD4850 GPU

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

[Bug 70569] New: DOTA2 background and other missing elements on HD4850 GPU

ine of cards. -- 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/20131017/b952b979/attachment.html>

[PATCH/RFC v3 00/19] Common Display Framework

Hi Tomi, Sorry for delayed response. On 10/11/2013 04:45 PM, Tomi Valkeinen wrote: > On 11/10/13 17:16, Andrzej Hajda wrote: > >> Picture size, content and format is the same on input and on output of DSI. >> The same bits which enters DSI appears on the output. Internally bits >> order can >>

[PATCH] drm: allocate crtc mutex separately from crtc

On Thu, Oct 17, 2013 at 1:35 AM, Ilija Hadzic wrote: > Embedding a mutex inside drm_crtc structure evokes a > subtle and rare corruption in drm_crtc_helper_set_config > failure-recovery path. > > Namely, if drm_crtc_helper_set_config takes the > path under 'fail:' label *and* some other process >

[PATCH] drm: allocate crtc mutex separately from crtc

> Can't we instead just copy the few things we need to restore back? > This wholesale structure copying has rather tricky semantics and is > bound to trick up someone else in the future. And indeed we seem to > have a similar (but less catastrophic) thing going on with crtc->fb I > think. Sure,

[Bug 70528] RadeonSI : Specviewperf10/proe-04 cause system hang

est Closed source "fglrx" driver -- 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/20131017/5aae7495/attachment.html>

[Bug 70528] RadeonSI : Specviewperf10/proe-04 cause system hang

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

[Bug 64475] Slow work and no brightness adjustment in Euro Track Simulator II game with HD6850

part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/23d14605/attachment.html>

[Bug 67367] No HDR effects on the Radeon HD6850 in all applications

Resolution|--- |INVALID -- 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/20131017/b81e56ce/attachment.html>

[Bug 70088] Glamor on r600g crashes Xserver

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20131017/e19cbabc/attachment.html>

[Bug 70528] RadeonSI : Specviewperf10/proe-04 cause system hang

attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131017/32722de3/attachment.html>

[Bug 67982] After boot, the APU is powered with its maximum voltage (trinity/ARUBA)

https://bugs.freedesktop.org/show_bug.cgi?id=67982 Kertesz Laszlo changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug 70514] Unresponsive system on boot with radeon + FireGL v7700

https://bugs.freedesktop.org/show_bug.cgi?id=70514 --- Comment #2 from Luke --- Kernel of the Arch Linux x64 mentioned previously: $ uname -r 3.11.5-1-ARCH As far as I know, this is not a regression. Some old live cds have the same problem: - Booting from an old Arch live-cd

[v3.10][v3.11][v3.12][Regression][PATCH 1/1] Revert "Revert "drm/i915: revert eDP bpp clamping code changes""

On Wed, Oct 16, 2013 at 04:34:57PM -0400, Joseph Salisbury wrote: > BugLink: http://bugs.launchpad.net/bugs/1195483 > > This reverts commit 657445fe8660100ad174600ebfa61536392b7624. > > Signed-off-by: Joseph Salisbury > Cc: Daniel Vetter > Cc: Paulo Zanoni > Cc: David Airlie > Cc: stable at