[PATCH] drm: don't unlock in the addfb error paths

We don't grab the modeset locks any more since commit 468174f748603497e73dba9b5c6d1d9f71121486 Author: Daniel Vetter Date: Tue Dec 11 00:09:12 2012 +0100 drm: push modeset_lock_all into ->fb_create driver callbacks Reported-by: Ray Strode Cc: Ray Strode Cc: Dave Airlie Signed-off-by:

[PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

On Wed, Mar 27, 2013 at 10:49:10AM +0100, Laurent Pinchart wrote: > Hi Simon, > > On Wednesday 27 March 2013 13:01:43 Simon Horman wrote: > > On Thu, Mar 14, 2013 at 03:35:46PM +0100, Laurent Pinchart wrote: > > > Only the DU0 VGA output is currently supported. Support for the DU0 LVDS > > > and

[PATCH 1/1] drm/exynos: drm_connector: Fix error check condition

2013/3/21 Sachin Kamat : > drm_add_edid_modes() returns 0 upon failure to find any modes. > Hence check for 0 and not less than 0. > > Signed-off-by: Sachin Kamat > Cc: Rahul Sharma > --- > drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +- > 1 files changed, 1 insertions(+), 1

[PATCH v2] drm/exynos: enable FIMD clocks

2013/3/20 Vikas Sajjan : > While migrating to common clock framework (CCF), found that the FIMD clocks > were pulled down by the CCF. > If CCF finds any clock(s) which has NOT been claimed by any of the > drivers, then such clock(s) are PULLed low by CCF. > > By calling clk_prepare_enable() for

[PATCH v4 09/21] modetest: Allow specifying plane position

On Wed, Mar 27, 2013 at 05:57:20PM +0200, Ville Syrj?l? wrote: > On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote: > > Extend the -P option to allow specifying the plane x and y offsets. The > > position is optional, if not specified the plane will be positioned at > > the center

[PATCH v4 09/21] modetest: Allow specifying plane position

On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote: > Extend the -P option to allow specifying the plane x and y offsets. The > position is optional, if not specified the plane will be positioned at > the center of the screen as before. > > Signed-off-by: Laurent Pinchart > --- >

[PATCH v3 4/4] drm/i915: Implement proper clipping for video sprites

From: Ville Syrj?l? Properly clip the source when the destination gets clipped by the pipe dimensions. Sadly the video sprite hardware is rather limited so it can't do proper sub-pixel postitioning. Resort to truncating the source coordinates to (macro)pixel

[PATCH v2 3/4] drm: Add drm_rect_debug_print()

From: Ville Syrj?l? Add a debug function to print the rectangle in a human readable format. v2: Renamed drm_region to drm_rect, the function from drm_region_debug to drm_rect_debug_print(), and use %+d instead of +%d in the format. Signed-off-by: Ville

[PATCH v3 2/4] drm: Add drm_rect_calc_{hscale, vscale}() utility functions

From: Ville Syrj?l? These functions calculcate the scaling factor based on the source and destination rectangles. There are two version of the functions, the strict ones that will return an error if the min/max scaling factor is exceeded, and the relaxed versions

[PATCH v3 1/4] drm: Add struct drm_rect and assorted utility functions

From: Ville Syrj?l? struct drm_rect represents a simple rectangle. The utility functions are there to help driver writers. v2: Moved the region stuff into its own file, made the smaller funcs static inline, used 64bit maths in the scaled clipping function to

[Bug 62573] [bisected] Half-Life 2: Deathmatch native version crashes

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130327/c7bf0607/attachment.html>

[PATCH 1/1] drm/exynos: drm_connector: Fix error check condition

On 27 March 2013 16:06, Inki Dae wrote: > 2013/3/21 Sachin Kamat : >> drm_add_edid_modes() returns 0 upon failure to find any modes. >> Hence check for 0 and not less than 0. >> >> Signed-off-by: Sachin Kamat >> Cc: Rahul Sharma >> --- >> drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +-

[PATCH Resend] drm/exynos: drm_connector: Fix error check condition

drm_add_edid_modes() returns 0 upon failure to find any modes. Hence check for 0 and not less than 0. Signed-off-by: Sachin Kamat Cc: Rahul Sharma --- drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git

[PATCHv2 1/3] pci: added pcie_get_speed_cap_mask function

On Tue, 2013-03-26 at 12:39 -0600, Bjorn Helgaas wrote: > But we also know pdev is a PCIe device, and I think a PCIe device on a > root bus must be a "Root Complex Integrated Endpoint" (PCIe spec sec > 1.3.2.3). Such a device does not have a link at all, so there's no > point in fiddling with its

[PATCH v2] drm/exynos: enable FIMD clocks

Hi, On 27 March 2013 15:53, Inki Dae wrote: > 2013/3/20 Vikas Sajjan : >> While migrating to common clock framework (CCF), found that the FIMD clocks >> were pulled down by the CCF. >> If CCF finds any clock(s) which has NOT been claimed by any of the >> drivers, then such clock(s) are PULLed

[RFC/PATCH] drm: Add XRGB8626262 (RGB 6:6:6) pixel format

On Wed, Mar 27, 2013 at 03:09:48PM +0100, Laurent Pinchart wrote: > Hi Ville, > > On Wednesday 27 March 2013 13:06:20 Ville Syrj?l? wrote: > > On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote: > > > This format is an odd beast, implemented by Renesas R-Car hardware. It > > >

[PATCH] drivers/gpu/drm/nouveau: remove erroneous semicolon

need remove semicolon, or always return true. Signed-off-by: Chen Gang --- drivers/gpu/drm/nouveau/nv50_display.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c index 7f0e6c3..1ddc03e

[RFC/PATCH] drm: Add XRGB8626262 (RGB 6:6:6) pixel format

Hi Ville, On Wednesday 27 March 2013 16:16:26 Ville Syrj?l? wrote: > On Wed, Mar 27, 2013 at 03:09:48PM +0100, Laurent Pinchart wrote: > > On Wednesday 27 March 2013 13:06:20 Ville Syrj?l? wrote: > > > On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote: > > > > This format is an odd

[PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

On Wed, Mar 27, 2013 at 12:56:37PM +0100, Danny Baumann wrote: > OK, I see. And there is user space depending on that behaviour? And > again - how is user space supposed to know about the behavioral > differences? Is it something like 'if type is raw, don't expect > anything'? "Do not rely upon

[RFC/PATCH] drm: Add XRGB8626262 (RGB 6:6:6) pixel format

Hi Ville, On Wednesday 27 March 2013 13:06:20 Ville Syrj?l? wrote: > On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote: > > This format is an odd beast, implemented by Renesas R-Car hardware. It > > stores RGB 6:6:6 pixels in 32 bits as > > > > [31:0] x:R:x:G:x:B:x 8:6:2:6:2:6:2

[PATCH v2 0/8] omapdss/omapdrm: Misc fixes and improvements

On Wednesday 27 March 2013 01:24 PM, Tomi Valkeinen wrote: > On 2013-03-26 15:45, Archit Taneja wrote: >> These are misc fixes and improvements within omapdrm and omapdss. The fixes >> do the >> following: >> >> - Make omapdrm smarter to choose the right overlay managers as it's crtcs. >> This

[PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

Hi, Well, the ACPI spec says this (section B.5.2): " The OEM may define the number 0 as "Zero brightness" that can mean to turn off the lighting (e.g. LCD panel backlight) in the device. This may be useful in the case of an output device that can still be viewed

[PATCH v2 6/8] omapdss: Features: Fix some parameter ranges

On Wednesday 27 March 2013 01:03 PM, Tomi Valkeinen wrote: > On 2013-03-26 15:45, Archit Taneja wrote: >> Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come >> because >> some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only >> OMAP5 ES2 in the kernel,

[RFC/PATCH] drm: Add XRGB8626262 (RGB 6:6:6) pixel format

On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote: > This format is an odd beast, implemented by Renesas R-Car hardware. It > stores RGB 6:6:6 pixels in 32 bits as > > [31:0] x:R:x:G:x:B:x 8:6:2:6:2:6:2 little endian > > Signed-off-by: Laurent Pinchart

[PATCH v2 5/8] omapdss: DISPC: add max pixel clock limits for LCD and TV managers

On Wednesday 27 March 2013 01:00 PM, Tomi Valkeinen wrote: > On 2013-03-26 15:45, Archit Taneja wrote: >> Each version of OMAP has a limitation on the maximum pixel clock frequency >> supported by an overlay manager. This limit isn't checked by omapdss. Add >> dispc feats for lcd and tv managers

[PATCH v3 3/8] drm/omap: Make fixed resolution panels work

On Wednesday 27 March 2013 12:54 PM, Tomi Valkeinen wrote: > On 2013-03-26 15:45, Archit Taneja wrote: >> The omapdrm driver requires omapdss panel drivers to expose ops like detect, >> set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, >> DSI >> and SDI drivers. At some

[PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

On Thu, Mar 14, 2013 at 03:35:46PM +0100, Laurent Pinchart wrote: > Only the DU0 VGA output is currently supported. Support for the DU0 LVDS > and DU1 LVDS outputs will require information about the panels that will > be connected to those outputs. > > Signed-off-by: Laurent Pinchart

[PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

Hi, >> Well, the ACPI spec says this (section B.5.2): >> >> " >> The OEM may define the number 0 as "Zero brightness" that can mean >> to turn off the lighting (e.g. LCD panel backlight) in the device. >> This may be useful in the case of an output device that can still be >> viewed using only

[PATCH 2/2] dma-buf: Add debugfs support

Hi Laurent! Thanks for the review: On 27 March 2013 05:38, Laurent Pinchart wrote: > Hi Sumit, > > Thanks for the patch. > > On Monday 25 March 2013 16:50:46 Sumit Semwal wrote: >> Add debugfs support to make it easier to print debug information >> about the dma-buf buffers. >> >> Cc: Dave

[Bug 55811] New: [Quadro NVS 5400M] graphic garbage/corruption/noise on resume

https://bugzilla.kernel.org/show_bug.cgi?id=55811 Summary: [Quadro NVS 5400M] graphic garbage/corruption/noise on resume Product: Drivers Version: 2.5 Kernel Version: 3.7.10-1.1-desktop Platform: All OS/Version: Linux

[Bug 62756] Rendering errors on rv790 with llvm and unigine heaven 3.0

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130327/4346d1cd/attachment.html>

[PATCHv2 1/3] pci: added pcie_get_speed_cap_mask function

On Wed, Mar 27, 2013 at 9:25 AM, Benjamin Herrenschmidt wrote: > On Tue, 2013-03-26 at 12:39 -0600, Bjorn Helgaas wrote: >> But we also know pdev is a PCIe device, and I think a PCIe device on a >> root bus must be a "Root Complex Integrated Endpoint" (PCIe spec sec >> 1.3.2.3). Such a device

[PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

Hi Simon, On Wednesday 27 March 2013 13:01:43 Simon Horman wrote: > On Thu, Mar 14, 2013 at 03:35:46PM +0100, Laurent Pinchart wrote: > > Only the DU0 VGA output is currently supported. Support for the DU0 LVDS > > and DU1 LVDS outputs will require information about the panels that will > > be

[ANNOUNCE] libdrm 2.4.43

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex Deucher (1): radeon: add pci ids for Richland APUs Ben Widawsky (1): intel_chipset: Merge intel-gpu-tools chipsets Benjamin Gaignard (2): tests: allow tests programs to be installed tests: allow tests programs to be

[RFC/PATCH] drm: Add XRGB8626262 (RGB 6:6:6) pixel format

This format is an odd beast, implemented by Renesas R-Car hardware. It stores RGB 6:6:6 pixels in 32 bits as [31:0] x:R:x:G:x:B:x 8:6:2:6:2:6:2 little endian Signed-off-by: Laurent Pinchart --- Hello, I came across this weird format on a Renesas

[PATCH v2 0/8] omapdss/omapdrm: Misc fixes and improvements

/misc_drm_dss Which of the fixes should go for 3.9? We need those separately, based on the mainline. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: <http://l

[PATCH v2 6/8] omapdss: Features: Fix some parameter ranges

think it's ever very clearly stated, though... Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130327/4a785c4e/attachment-0001.pgp>

[PATCH v2 5/8] omapdss: DISPC: add max pixel clock limits for LCD and TV managers

0, > .calc_scaling = dispc_ovl_calc_scaling_24xx, > .calc_core_clk = calc_core_clk_24xx, > .num_fifos = 3, OMAP2 has VENC output, but there's no max_tv_pclk above. This would make VENC pclk check to fail always, wouldn't it? Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130327/edfa563f/attachment-0001.pgp>

[PATCH v3 3/8] drm/omap: Make fixed resolution panels work

- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130327/0bef7539/attachment-0001.pgp>

[PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

On Wed, Mar 27, 2013 at 8:56 AM, Danny Baumann wrote: > Hi, > > Well, the ACPI spec says this (section B.5.2): > > " > The OEM may define the number 0 as "Zero brightness" that can mean > to turn off the lighting (e.g. LCD panel backlight) in the device. > This may be

[PATCHv2 5/5] videomode: videomode_from_timing work

We currently have videomode_from_timing(), which takes one display_timing entry from display_timings. To make it easier to use display_timing without display_timings, this patch renames videomode_from_timing() to videomode_from_timings(), and adds a new videomode_from_timing() which just converts

[PATCHv2 4/5] videomode: remove timing_entry_index

Display timing's fields have minimum, typical and maximum values. These can be accessed by using timing_entry_index enum, and display_timing_get_value() function. There's no real need for this extra complexity. The values can be accessed more easily by just using the min/typ/max fields.

[PATCHv2 3/5] videomode: create enum for videomode's display flags

Instead of having plain defines for the videomode's flags, add an enum for the flags. This makes the flags clearer to use, as the enum tells which values can be used with the flags field. Signed-off-by: Tomi Valkeinen Cc: Steffen Trumtrar --- include/video/display_timing.h | 28

[PATCHv2 2/5] videomode: combine videomode dmt_flags and data_flags

Both videomode and display_timing contain flags describing the modes. These are stored in dmt_flags and data_flags. There's no need to separate these flags, and having separate fields just makes the flags more difficult to use. This patch combines the fields and renames VESA_DMT_* flags to

[PATCHv2 1/5] videomode: simplify videomode Kconfig and Makefile

This patch simplifies videomode related Kconfig and Makefile. After this patch, there's only one non-user selectable Kconfig option left, VIDEOMODE_HELPERS. The reasons for the change: * Videomode helper functions are not something that should be shown in the kernel configuration options. The

[PATCHv2 0/5] videomode patches

Hi, Here's a v2 of the videomode series. The changes compared to v1: * Dropped "videomode: rename fields", as it received only negative comments * New patch: "videomode: videomode_from_timing work" Patches 1-4 are unchanged. Tomi Tomi Valkeinen (5): videomode: simplify videomode Kconfig

[PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

On Wed, Mar 27, 2013 at 7:56 AM, Danny Baumann wrote: > Hi, > >>> Well, the ACPI spec says this (section B.5.2): >>> >>> " >>> The OEM may define the number 0 as "Zero brightness" that can mean >>> to turn off the lighting (e.g. LCD panel backlight) in the device. >>> This may be useful in the

[PATCH 1/4] drm/tilcdc: Fix an incorrect condition

- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 899 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130327/56c3da23/attachment-0001.pgp>

[Nouveau] [PATCH] drm/nouveau: Ack interrupts for some fuc engines

Op 26-03-13 21:29, Marcin Slusarz schreef: > On Tue, Mar 26, 2013 at 07:29:24AM +0100, Maarten Lankhorst wrote: >> Op 25-03-13 19:14, Marcin Slusarz schreef: >>> On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote: Fixes 100% cpu usage when the exit interrupt never got acked.

[PATCH 2/2] dma-buf: Add debugfs support

Hi Sumit, Thanks for the patch. On Monday 25 March 2013 16:50:46 Sumit Semwal wrote: > Add debugfs support to make it easier to print debug information > about the dma-buf buffers. > > Cc: Dave Airlie > [minor fixes on init and warning fix] > Signed-off-by: Sumit Semwal > --- > changes since

Re: [PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

On Thu, Mar 14, 2013 at 03:35:46PM +0100, Laurent Pinchart wrote: Only the DU0 VGA output is currently supported. Support for the DU0 LVDS and DU1 LVDS outputs will require information about the panels that will be connected to those outputs. Signed-off-by: Laurent Pinchart

Re: [Nouveau] [PATCH] drm/nouveau: Ack interrupts for some fuc engines

Op 26-03-13 21:29, Marcin Slusarz schreef: On Tue, Mar 26, 2013 at 07:29:24AM +0100, Maarten Lankhorst wrote: Op 25-03-13 19:14, Marcin Slusarz schreef: On Mon, Mar 25, 2013 at 10:22:37AM +0100, Maarten Lankhorst wrote: Fixes 100% cpu usage when the exit interrupt never got acked.

Re: [PATCH 2/2] dma-buf: Add debugfs support

Hi Laurent! Thanks for the review: On 27 March 2013 05:38, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Sumit, Thanks for the patch. On Monday 25 March 2013 16:50:46 Sumit Semwal wrote: Add debugfs support to make it easier to print debug information about the dma-buf

Re: [PATCH v3 3/8] drm/omap: Make fixed resolution panels work

On Wednesday 27 March 2013 12:54 PM, Tomi Valkeinen wrote: On 2013-03-26 15:45, Archit Taneja wrote: The omapdrm driver requires omapdss panel drivers to expose ops like detect, set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI and SDI drivers. At some places, there

Re: [PATCH v2 5/8] omapdss: DISPC: add max pixel clock limits for LCD and TV managers

On Wednesday 27 March 2013 01:00 PM, Tomi Valkeinen wrote: On 2013-03-26 15:45, Archit Taneja wrote: Each version of OMAP has a limitation on the maximum pixel clock frequency supported by an overlay manager. This limit isn't checked by omapdss. Add dispc feats for lcd and tv managers and check

Re: [PATCH v2 6/8] omapdss: Features: Fix some parameter ranges

On Wednesday 27 March 2013 01:03 PM, Tomi Valkeinen wrote: On 2013-03-26 15:45, Archit Taneja wrote: Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come because some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only OMAP5 ES2 in the kernel, so replace

Re: [PATCH v2 0/8] omapdss/omapdrm: Misc fixes and improvements

On Wednesday 27 March 2013 01:24 PM, Tomi Valkeinen wrote: On 2013-03-26 15:45, Archit Taneja wrote: These are misc fixes and improvements within omapdrm and omapdss. The fixes do the following: - Make omapdrm smarter to choose the right overlay managers as it's crtcs. This makes sure that

Re: [PATCH 1/4] drm/tilcdc: Fix an incorrect condition

Hi, On 2013-03-25 15:36, Rob Clark wrote: sorry, was offline for a while (moving), and missed the last email.. I would guess that Tomi would send pull-req for tilcdc and omapdrm. Well I suppose I could do it if Tomi can't, although my pandas/beagles/beaglebones are not unpacked yet.. Well,

[PATCHv2 0/5] videomode patches

Hi, Here's a v2 of the videomode series. The changes compared to v1: * Dropped videomode: rename fields, as it received only negative comments * New patch: videomode: videomode_from_timing work Patches 1-4 are unchanged. Tomi Tomi Valkeinen (5): videomode: simplify videomode Kconfig and

[PATCHv2 1/5] videomode: simplify videomode Kconfig and Makefile

This patch simplifies videomode related Kconfig and Makefile. After this patch, there's only one non-user selectable Kconfig option left, VIDEOMODE_HELPERS. The reasons for the change: * Videomode helper functions are not something that should be shown in the kernel configuration options. The

[PATCHv2 2/5] videomode: combine videomode dmt_flags and data_flags

Both videomode and display_timing contain flags describing the modes. These are stored in dmt_flags and data_flags. There's no need to separate these flags, and having separate fields just makes the flags more difficult to use. This patch combines the fields and renames VESA_DMT_* flags to

[PATCHv2 3/5] videomode: create enum for videomode's display flags

Instead of having plain defines for the videomode's flags, add an enum for the flags. This makes the flags clearer to use, as the enum tells which values can be used with the flags field. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Cc: Steffen Trumtrar s.trumt...@pengutronix.de ---

[PATCHv2 4/5] videomode: remove timing_entry_index

Display timing's fields have minimum, typical and maximum values. These can be accessed by using timing_entry_index enum, and display_timing_get_value() function. There's no real need for this extra complexity. The values can be accessed more easily by just using the min/typ/max fields.

[PATCHv2 5/5] videomode: videomode_from_timing work

We currently have videomode_from_timing(), which takes one display_timing entry from display_timings. To make it easier to use display_timing without display_timings, this patch renames videomode_from_timing() to videomode_from_timings(), and adds a new videomode_from_timing() which just converts

[PATCH] drivers/gpu/drm/nouveau: remove erroneous semicolon

need remove semicolon, or always return true. Signed-off-by: Chen Gang gang.c...@asianux.com --- drivers/gpu/drm/nouveau/nv50_display.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c

Re: [PATCH v3 3/8] drm/omap: Make fixed resolution panels work

On 2013-03-26 15:45, Archit Taneja wrote: The omapdrm driver requires omapdss panel drivers to expose ops like detect, set_timings and check_timings. These can be NULL for fixed panel DPI, DBI, DSI and SDI drivers. At some places, there are no checks to see if the panel driver has these ops

Re: [PATCH v2 5/8] omapdss: DISPC: add max pixel clock limits for LCD and TV managers

On 2013-03-26 15:45, Archit Taneja wrote: Each version of OMAP has a limitation on the maximum pixel clock frequency supported by an overlay manager. This limit isn't checked by omapdss. Add dispc feats for lcd and tv managers and check whether the target timings can be supported or not.

Re: [PATCH v2 6/8] omapdss: Features: Fix some parameter ranges

On 2013-03-26 15:45, Archit Taneja wrote: Increase the DSS_FCLK and DSI_FCLK max supported frequencies, these come because some frequencies were increased from OMAP5 ES1 to OMAP5 ES2. We support only OMAP5 ES2 in the kernel, so replace the ES1 values with ES2 values. Increase the DSI PLL

Re: [PATCH v2 0/8] omapdss/omapdrm: Misc fixes and improvements

On 2013-03-26 15:45, Archit Taneja wrote: These are misc fixes and improvements within omapdrm and omapdss. The fixes do the following: - Make omapdrm smarter to choose the right overlay managers as it's crtcs. This makes sure that omapdrm is functional for OMAP platforms with

[ANNOUNCE] libdrm 2.4.43

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex Deucher (1): radeon: add pci ids for Richland APUs Ben Widawsky (1): intel_chipset: Merge intel-gpu-tools chipsets Benjamin Gaignard (2): tests: allow tests programs to be installed tests: allow tests programs to be

Re: [PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

Hi Simon, On Wednesday 27 March 2013 13:01:43 Simon Horman wrote: On Thu, Mar 14, 2013 at 03:35:46PM +0100, Laurent Pinchart wrote: Only the DU0 VGA output is currently supported. Support for the DU0 LVDS and DU1 LVDS outputs will require information about the panels that will be connected

[RFC/PATCH] drm: Add XRGB8626262 (RGB 6:6:6) pixel format

This format is an odd beast, implemented by Renesas R-Car hardware. It stores RGB 6:6:6 pixels in 32 bits as [31:0] x:R:x:G:x:B:x 8:6:2:6:2:6:2 little endian Signed-off-by: Laurent Pinchart laurent.pinchart+rene...@ideasonboard.com --- Hello, I came across this weird format on a Renesas SoC

Re: [PATCH v2] drm/exynos: enable FIMD clocks

2013/3/20 Vikas Sajjan vikas.saj...@linaro.org: While migrating to common clock framework (CCF), found that the FIMD clocks were pulled down by the CCF. If CCF finds any clock(s) which has NOT been claimed by any of the drivers, then such clock(s) are PULLed low by CCF. By calling

Re: [PATCH 1/1] drm/exynos: drm_connector: Fix error check condition

2013/3/21 Sachin Kamat sachin.ka...@linaro.org: drm_add_edid_modes() returns 0 upon failure to find any modes. Hence check for 0 and not less than 0. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Cc: Rahul Sharma rahul.sha...@samsung.com ---

[Bug 62756] Rendering errors on rv790 with llvm and unigine heaven 3.0

https://bugs.freedesktop.org/show_bug.cgi?id=62756 --- Comment #2 from Andy Furniss li...@andyfurniss.entadsl.com --- (In reply to comment #1) (In reply to comment #1) I tried finding a working commit going back with mesa, but I get to a point where llvm renders nothing at all with anything

Re: [RFC/PATCH] drm: Add XRGB8626262 (RGB 6:6:6) pixel format

On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote: This format is an odd beast, implemented by Renesas R-Car hardware. It stores RGB 6:6:6 pixels in 32 bits as [31:0] x:R:x:G:x:B:x 8:6:2:6:2:6:2 little endian Signed-off-by: Laurent Pinchart

[Bug 55811] New: [Quadro NVS 5400M] graphic garbage/corruption/noise on resume

https://bugzilla.kernel.org/show_bug.cgi?id=55811 Summary: [Quadro NVS 5400M] graphic garbage/corruption/noise on resume Product: Drivers Version: 2.5 Kernel Version: 3.7.10-1.1-desktop Platform: All OS/Version: Linux

Re: [PATCH v2 3/3] ARM: shmobile: marzen: Add Display Unit support

On Wed, Mar 27, 2013 at 10:49:10AM +0100, Laurent Pinchart wrote: Hi Simon, On Wednesday 27 March 2013 13:01:43 Simon Horman wrote: On Thu, Mar 14, 2013 at 03:35:46PM +0100, Laurent Pinchart wrote: Only the DU0 VGA output is currently supported. Support for the DU0 LVDS and DU1 LVDS

Re: [PATCH v2] drm/exynos: enable FIMD clocks

Hi, On 27 March 2013 15:53, Inki Dae inki@samsung.com wrote: 2013/3/20 Vikas Sajjan vikas.saj...@linaro.org: While migrating to common clock framework (CCF), found that the FIMD clocks were pulled down by the CCF. If CCF finds any clock(s) which has NOT been claimed by any of the

[PATCH Resend] drm/exynos: drm_connector: Fix error check condition

drm_add_edid_modes() returns 0 upon failure to find any modes. Hence check for 0 and not less than 0. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Cc: Rahul Sharma rahul.sha...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_connector.c |2 +- 1 files changed, 1 insertions(+), 1

Re: [PATCH 1/1] drm/exynos: drm_connector: Fix error check condition

On 27 March 2013 16:06, Inki Dae inki@samsung.com wrote: 2013/3/21 Sachin Kamat sachin.ka...@linaro.org: drm_add_edid_modes() returns 0 upon failure to find any modes. Hence check for 0 and not less than 0. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Cc: Rahul Sharma

Re: [PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

Hi, Well, the ACPI spec says this (section B.5.2): The OEM may define the number 0 as Zero brightness that can mean to turn off the lighting (e.g. LCD panel backlight) in the device. This may be useful in the case of an output device that can still be viewed using only ambient light, for

Re: [PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

On Wed, Mar 27, 2013 at 7:56 AM, Danny Baumann dannybaum...@web.de wrote: Hi, Well, the ACPI spec says this (section B.5.2): The OEM may define the number 0 as Zero brightness that can mean to turn off the lighting (e.g. LCD panel backlight) in the device. This may be useful in the case

Re: [PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

On Wed, Mar 27, 2013 at 8:56 AM, Danny Baumann dannybaum...@web.de wrote: Hi, Well, the ACPI spec says this (section B.5.2): The OEM may define the number 0 as Zero brightness that can mean to turn off the lighting (e.g. LCD panel backlight) in the device. This may be useful in the case

Re: [RFC/PATCH] drm: Add XRGB8626262 (RGB 6:6:6) pixel format

Hi Ville, On Wednesday 27 March 2013 13:06:20 Ville Syrjälä wrote: On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote: This format is an odd beast, implemented by Renesas R-Car hardware. It stores RGB 6:6:6 pixels in 32 bits as [31:0] x:R:x:G:x:B:x 8:6:2:6:2:6:2 little

Re: [RFC/PATCH] drm: Add XRGB8626262 (RGB 6:6:6) pixel format

On Wed, Mar 27, 2013 at 03:09:48PM +0100, Laurent Pinchart wrote: Hi Ville, On Wednesday 27 March 2013 13:06:20 Ville Syrjälä wrote: On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote: This format is an odd beast, implemented by Renesas R-Car hardware. It stores RGB 6:6:6

Re: [RFC/PATCH] drm: Add XRGB8626262 (RGB 6:6:6) pixel format

Hi Ville, On Wednesday 27 March 2013 16:16:26 Ville Syrjälä wrote: On Wed, Mar 27, 2013 at 03:09:48PM +0100, Laurent Pinchart wrote: On Wednesday 27 March 2013 13:06:20 Ville Syrjälä wrote: On Wed, Mar 27, 2013 at 10:19:29AM +0100, Laurent Pinchart wrote: This format is an odd beast,

Re: [PATCH 0/1] drm/i915: Allow specifying a minimum brightness level for sysfs control.

On Wed, Mar 27, 2013 at 12:56:37PM +0100, Danny Baumann wrote: OK, I see. And there is user space depending on that behaviour? And again - how is user space supposed to know about the behavioral differences? Is it something like 'if type is raw, don't expect anything'? Do not rely upon 0

Re: [PATCHv2 1/3] pci: added pcie_get_speed_cap_mask function

On Tue, 2013-03-26 at 12:39 -0600, Bjorn Helgaas wrote: But we also know pdev is a PCIe device, and I think a PCIe device on a root bus must be a Root Complex Integrated Endpoint (PCIe spec sec 1.3.2.3). Such a device does not have a link at all, so there's no point in fiddling with its link

[PATCH v3 1/4] drm: Add struct drm_rect and assorted utility functions

From: Ville Syrjälä ville.syrj...@linux.intel.com struct drm_rect represents a simple rectangle. The utility functions are there to help driver writers. v2: Moved the region stuff into its own file, made the smaller funcs static inline, used 64bit maths in the scaled clipping function to

[PATCH v3 2/4] drm: Add drm_rect_calc_{hscale, vscale}() utility functions

From: Ville Syrjälä ville.syrj...@linux.intel.com These functions calculcate the scaling factor based on the source and destination rectangles. There are two version of the functions, the strict ones that will return an error if the min/max scaling factor is exceeded, and the relaxed versions

[PATCH v2 3/4] drm: Add drm_rect_debug_print()

From: Ville Syrjälä ville.syrj...@linux.intel.com Add a debug function to print the rectangle in a human readable format. v2: Renamed drm_region to drm_rect, the function from drm_region_debug to drm_rect_debug_print(), and use %+d instead of +%d in the format. Signed-off-by: Ville Syrjälä

[PATCH v3 4/4] drm/i915: Implement proper clipping for video sprites

From: Ville Syrjälä ville.syrj...@linux.intel.com Properly clip the source when the destination gets clipped by the pipe dimensions. Sadly the video sprite hardware is rather limited so it can't do proper sub-pixel postitioning. Resort to truncating the source coordinates to (macro)pixel

[Bug 62573] [bisected] Half-Life 2: Deathmatch native version crashes

https://bugs.freedesktop.org/show_bug.cgi?id=62573 Andreas Boll andreas.boll@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED

Re: [PATCHv2 1/3] pci: added pcie_get_speed_cap_mask function

On Wed, Mar 27, 2013 at 9:25 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Tue, 2013-03-26 at 12:39 -0600, Bjorn Helgaas wrote: But we also know pdev is a PCIe device, and I think a PCIe device on a root bus must be a Root Complex Integrated Endpoint (PCIe spec sec 1.3.2.3).

Re: [PATCH v4 09/21] modetest: Allow specifying plane position

On Wed, Mar 27, 2013 at 05:57:20PM +0200, Ville Syrjälä wrote: On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote: Extend the -P option to allow specifying the plane x and y offsets. The position is optional, if not specified the plane will be positioned at the center of the

[PATCH] drm: don't unlock in the addfb error paths

We don't grab the modeset locks any more since commit 468174f748603497e73dba9b5c6d1d9f71121486 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Tue Dec 11 00:09:12 2012 +0100 drm: push modeset_lock_all into -fb_create driver callbacks Reported-by: Ray Strode rstr...@redhat.com Cc: Ray

Re: [PATCH v4 09/21] modetest: Allow specifying plane position

Hi Ville, On Wednesday 27 March 2013 17:57:20 Ville Syrjälä wrote: On Tue, Mar 19, 2013 at 03:55:50PM +0100, Laurent Pinchart wrote: Extend the -P option to allow specifying the plane x and y offsets. The position is optional, if not specified the plane will be positioned at the center of