[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

eiving 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/20141201/c44f85a3/attachment.html>

[PATCH v5 3/3] drm: panel: simple-panel: add bus format information for foxlink panel

Foxlink's fl500wvr00-a0t supports RGB888 format. Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panel/panel-simple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 66838a5..695f406 100644 ---

[PATCH v5 2/3] drm: panel: simple-panel: add support for bus_format retrieval

Provide a way to specify panel requirement in terms of supported media bus format (particularly useful for panels connected to an RGB or LVDS bus). Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panel/panel-simple.c | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH v5 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

Add bus_formats and num_bus_formats fields and drm_display_info_set_bus_formats helper function to specify the bus formats supported by a given display. This information can be used by display controller drivers to configure the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw

[PATCH v5 0/3] drm: describe display bus format

Hello, This series makes use of the MEDIA_BUS_FMT definition to describe how the data are transmitted to the display. This will allow drivers to configure their output display bus according to the display capabilities. For example some display controllers support DPI (or raw RGB) connectors and

[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

Hi Thierry, On Mon, 1 Dec 2014 16:42:58 +0100 Thierry Reding wrote: > On Mon, Dec 01, 2014 at 09:20:59AM +0100, Boris Brezillon wrote: > > Add bus_formats and num_bus_formats fields and > > drm_display_info_set_bus_formats helper function to specify the bus > > formats supported by a given

[PATCH] drm/gma500: add support for atom e6xx lpc lvds i2c

On Fri, Sep 26, 2014 at 10:40 AM, Jan Safrata wrote: > add gpio bitbanging i2c adapter on LPC device of atom e6xx > gpu chipset to access lvds EDID > tested on SECO QuadMo747-E6xx-EXTREME Qseven platform > > Cc: Patrik Jakobsson > Signed-off-by: Jan Safrata > --- >

[PATCH v13 07/12] drm: bridge/dw_hdmi: add support for multi-byte register width access

Hi Philipp: On 2014年12月01日 20:04, Philipp Zabel wrote: > Am Freitag, den 28.11.2014, 17:43 +0800 schrieb Andy Yan: >> Hi Zabel: >> On 2014年11月27日 00:34, Philipp Zabel wrote: >>> Am Mittwoch, den 26.11.2014, 21:32 +0800 schrieb Andy Yan: On rockchip rk3288, only word(32-bit)

[PATCH v14 05/12] drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi

Hi Philipp: On 2014年12月01日 19:42, Philipp Zabel wrote: > Hi Andy, > > Am Montag, den 01.12.2014, 19:24 +0800 schrieb Andy Yan: > [...] >> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h >> new file mode 100644 >> index 000..1bbf3ca >> --- /dev/null >> +++

omapdrm/pvr kernel crash with camera capture and display application

278/0x398) [ 114.062988] [<80058590>] (worker_thread+0x0/0x398) from [<800600d4>] (kthread+0xbc/0xcc) [ 114.062988] [<80060018>] (kthread+0x0/0xcc) from [<8000ee18>] (ret_from_fork+0x14/0x20) [ 114.063018] r7: r6: r5:80060018 r4:ef0a5e58 [ 114.063018] Code: e24cb004 e52de004 e8bd4000 e59031cc (e5130014) [ 114.063018] ---[ end trace 2441b1bbdffd41f0 ]--- [ 114.063018] Fixing recursive fault but reboot is needed! -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/1ea00b3a/attachment-0001.html>

[PATCH v14 12/12] drm: bridge/dw_hdmi: add rockchip rk3288 support

Rockchip RK3288 hdmi is compatible with dw_hdmi this patch is depend on patch by Mark Yao Add drm driver for Rockchip Socs see https://lkml.org/lkml/2014/11/19/1153 Signed-off-by: Andy Yan --- Changes in v14: None Changes in v13: None Changes in v12: - add comment for the depend on patch

[PATCH v14 11/12] dt-bindings: Add documentation for rockchip dw hdmi

Signed-off-by: Andy Yan --- Changes in v14: None Changes in v13: None Changes in v12: None Changes in v11: None Changes in v10: None Changes in v9: None Changes in v8: - Add documentation for rockchip dw hdmi Changes in v7: None Changes in v6: None Changes in v5: None Changes in v4: None

[PATCH v14 10/12] drm: bridge/dw_hdmi: add function dw_hdmi_phy_enable_spare

RK3288 HDMI will not work without the spare bit of HDMI_PHY_CONF0 enable Signed-off-by: Andy Yan --- Changes in v14: None Changes in v13: None Changes in v12: None Changes in v11: None Changes in v10: None Changes in v9: None Changes in v8: None Changes in v7: None Changes in v6: None Changes

[PATCH v14 09/12] drm: bridge/dw_hdmi: clear i2cmphy_stat0 reg in hdmi_phy_wait_i2c_done

HDMI_IH_I2CMPHY_STAT0 is a clear on write register, which indicates i2cm operation status(i2c transfer done or error), every hdmi phy register configuration must check this register to make sure the configuration has complete. But the indication bit should be cleared after check, otherwise the

[PATCH v14 08/12] drm: bridge/dw_hdmi: add mode_valid support

some platform may not support all the display mode, add mode_valid interface check it Signed-off-by: Andy Yan --- Changes in v14: - remove drm_connector_register, because imx-drm core has registered connector Changes in v13: None Changes in v12: None Changes in v11: None Changes in v10: None

[PATCH v14 07/12] drm: bridge/dw_hdmi: add support for multi-byte register width access

On rockchip rk3288, only word(32-bit) accesses are permitted for hdmi registers. Byte width accesses (writeb, readb) generate an imprecise external abort. Signed-off-by: Andy Yan --- Changes in v14: None Changes in v13: None Changes in v12: None Changes in v11: None Changes in v10: None

[PATCH v14 06/12] dt-bindings: add document for dw_hdmi

Signed-off-by: Andy Yan --- Changes in v14: None Changes in v13: None Changes in v12: None Changes in v11: None Changes in v10: None Changes in v9: None Changes in v8: - correct some spelling mistake - modify ddc-i2c-bus and interrupt description Changes in v7: None Changes in v6: None Changes

[PATCH v14 05/12] drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi

the original imx hdmi driver is under drm/imx/, which depends on imx-drm, so move the imx hdmi driver out to drm/bridge and rename it to dw_hdmi Signed-off-by: Andy Yan --- Changes in v14: None Changes in v13: None Changes in v12: None Changes in v11: None Changes in v10: None Changes in v9:

[PATCH v14 04/12] drm: imx: imx-hdmi: split phy configuration to platform driver

hdmi phy configuration is platform specific, which can be adusted according to the board to get the best SI Signed-off-by: Andy Yan --- Changes in v14: None Changes in v13: - split phy configuration from patch#4 Changes in v12: None Changes in v11: None Changes in v10: None Changes in v9:

[PATCH v14 03/12] drm: imx: imx-hdmi: convert imx-hdmi to drm_bridge mode

IMX6 and Rockchip RK3288 and JZ4780 (Ingenic Xburst/MIPS) use the interface compatible Designware HDMI IP, but they also have some lightly differences, such as phy pll configuration, register width, 4K support, clk useage, and the crtc mux configuration is also platform specific. To reuse the imx

[PATCH v14 02/12] drm: imx: imx-hdmi: return defer if can't get ddc i2c adapter

drm driver may probe before the i2c bus, so the driver should defer probing until it is available Signed-off-by: Andy Yan Reviewed-by: Daniel Kurtz --- Changes in v14: None Changes in v13: None Changes in v12: - refactor of_node_put(ddc_node) Changes in v11: None Changes in v10: None Changes

[PATCH v14 01/12] drm: imx: imx-hdmi: make checkpatch happy

CHECK: Alignment should match open parenthesis + if ((hdmi->vic == 10) || (hdmi->vic == 11) || + (hdmi->vic == 12) || (hdmi->vic == 13) || CHECK: braces {} should be used on all arms of this statement + if (hdmi->hdmi_data.video_mode.mdvi) [...] + else { [...]

[PATCH v14 0/12] dw-hdmi: convert imx hdmi to bridge/dw_hdmi

We found Freescale imx6 and Rockchip rk3288 and Ingenic JZ4780 (Xburst/MIPS) use the interface compatible Designware HDMI IP, but they also have some lightly differences, such as phy pll configuration, register width(imx hdmi register is one byte, but rk3288 is 4 bytes width and can only be

[PATCH] drm/i915 Trouble with minimum brightness

On 12/01/2014 03:04 PM, Jani Nikula wrote: > On Fri, 28 Nov 2014, Jay Aurabind wrote: >> Hello all, >> >> I notice that some activity has been going on with the minimum value >> of display brightness recently (e1c412e7575). >> >> But the minimum value thats currently chosen is not at all

[PATCH 3/6] drm/edid: new drm_edid_block_checksum helper function V3

On Sun, Nov 30, 2014 at 07:57:43PM +0100, Stefan Brüns wrote: > The function will also be used by a later patch, so factor it out. > > V2: make raw_edid const, define/declare before first use > V3: fix erroneuos removal of csum variable > > Signed-off-by: Stefan Brüns > Reviewed-by: Jani

drm: exynos: mixer: fix using usleep() in atomic context

On 2014-12-01 16:54, Thierry Reding wrote: > On Sun, Nov 30, 2014 at 01:35:25AM +0100, tjakobi at math.uni-bielefeld.de > wrote: >> From: Tomasz Stanislawski >> >> This patch fixes calling usleep_range() after taking reg_slock >> using spin_lock_irqsave(). The mdelay() is used instead. >>

[PATCH 1/1] GPU-DRM-MSM: Deletion of unnecessary checks before two function calls

Dave will take them directly). Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/11f42aa7/attachment.sig>

[PATCH 1/1] GPU-DRM-MSM-Adreno: Deletion of unnecessary checks before the function call "release_firmware"

le Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/10bc8e41/attachment.sig>

[Bug 86267] [drm:evergreen_resume] *ERROR* evergreen startup failed on resume

... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/3cb50a09/attachment.html>

[PATCH 2/2] drm/msm/hdmi: add hdmi hdcp support

Add HDMI HDCP support including HDCP PartI/II/III authentication. Signed-off-by: Jilai Wang --- drivers/gpu/drm/msm/Makefile |1 + drivers/gpu/drm/msm/hdmi/hdmi.c | 44 + drivers/gpu/drm/msm/hdmi/hdmi.h | 31 + drivers/gpu/drm/msm/hdmi/hdmi_audio.c |

drm: exynos: mixer: fix using usleep() in atomic context

: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/e30b9bbe/attachment.sig>

[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

us_formats); I think you'll want to call kfree() on the bus_formats array from drm_connector_cleanup() as well to make sure you don't leak this on driver unload. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/ec921883/attachment.sig>

[PATCH 2/3] hdmi: added unpack and logging functions for InfoFrames

On Mon, Dec 01, 2014 at 04:33:31PM +0100, Thierry Reding wrote: > On Mon, Dec 01, 2014 at 02:48:47PM +0100, Hans Verkuil wrote: > > Hi Thierry, > > > > Thanks for the review, see my comments below. > > > > On 12/01/2014 02:15 PM, Thierry Reding wrote: > > > On Fri, Nov 28, 2014 at 03:50:50PM

[PATCH 2/3] hdmi: added unpack and logging functions for InfoFrames

o be WARN? It's perfectly legal for future > > devices to expose new types of infoframes. Perhaps even expected. But if > > we want to keep this here to help get bug reports so that we don't > > forget to update this code, then maybe we should do the same wherever we > > query the name of enum values above. > > I'll drop the WARN from the log function. I think it should also be dropped > from the unpack. The only place it makes sense is for pack() since there the > data comes from the driver, not from an external source. Sounds good. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/df0abddb/attachment-0001.sig>

[PATCH libdrm] drm: Avoid out of bound write in drmOpenByName()

On Mon, Dec 01, 2014 at 02:07:03PM +, Damien Lespiau wrote: > In the fallback code that looks for devices in /proc, the read() may > return with -1 in case of error (interruption from a signal for > instance). We'll then happily write '\0' to buf[-2]. > > As we didn't really care about the

RFC on upstreaming of a Mediatek DRM modesetting driver

On Mon, Dec 01, 2014 at 10:01:37AM +, Frank Binns wrote: > Hi, > > We are currently in negotiations with one of our customers (Mediatek) on > a strategy that will allow them to push a DRM modesetting driver into > the upstream kernel. We are writing to get people's opinions and > feedback on

[PATCH RESEND v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

Am Montag, den 01.12.2014, 09:42 +0100 schrieb Boris Brezillon: > Add bus_formats and num_bus_formats fields and > drm_display_info_set_bus_formats helper function to specify the bus > formats supported by a given display. > > This information can be used by display controller drivers to

[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

Hi Philipp, On Mon, 01 Dec 2014 16:06:26 +0100 Philipp Zabel wrote: > Am Montag, den 01.12.2014, 09:20 +0100 schrieb Boris Brezillon: > > Add bus_formats and num_bus_formats fields and > > drm_display_info_set_bus_formats helper function to specify the bus > > formats supported by a given

build regression with "rcar-du: Remove platform data support"

On Monday 01 December 2014 15:25:06 Laurent Pinchart wrote: > On Monday 01 December 2014 14:09:36 Arnd Bergmann wrote: > > Hi Laurent, > > > > linux-next has failed to build with lager_defconfig and marzen_defconfig for > > a while, with this error: > > > >

[PATCH 0/2] Fix legacy boards compilation breakage with DU

On Friday 28 November 2014 10:17:33 Laurent Pinchart wrote: > On Friday 28 November 2014 09:18:46 Simon Horman wrote: > > [CCed Magnus, ARM SoC maintainers] > > > > On Thu, Nov 27, 2014 at 05:19:11PM +0200, Laurent Pinchart wrote: > > > Hello, > > > > > > The DU driver has lost support for

[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

Am Montag, den 01.12.2014, 09:20 +0100 schrieb Boris Brezillon: > Add bus_formats and num_bus_formats fields and > drm_display_info_set_bus_formats helper function to specify the bus > formats supported by a given display. > > This information can be used by display controller drivers to

[PATCH 1/2] drm/msm/hdmi: add register description for HDMI HDCP support

Add HDCP related register description. Signed-off-by: Jiali Wang --- drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 76 + 1 file changed, 60 insertions(+), 16 deletions(-) diff --git a/drivers/gpu/drm/msm/hdmi/hdmi.xml.h b/drivers/gpu/drm/msm/hdmi/hdmi.xml.h index

[PATCH] rnndb: Add register fields for msm/hdmi HDCP support

This patch adds the field description for HDMI HDCP registers. Signed-off-by: Jilai Wang --- rnndb/hdmi/hdmi.xml | 46 -- 1 file changed, 40 insertions(+), 6 deletions(-) diff --git a/rnndb/hdmi/hdmi.xml b/rnndb/hdmi/hdmi.xml index 64393b4..c67e6c1

[PATCH 01/10] drm: add helper to get crtc timings (v5)

From: Gustavo Padovan We need to get hdisplay and vdisplay in a few places so create a helper to make our job easier. Note that drm_crtc_check_viewport() and intel_modeset_pipe_config() were previously making adjustments for doublescan modes and vscan > 1 modes,

build regression with "rcar-du: Remove platform data support"

Hi Arnd, On Monday 01 December 2014 14:09:36 Arnd Bergmann wrote: > Hi Laurent, > > linux-next has failed to build with lager_defconfig and marzen_defconfig for > a while, with this error: > > arch/arm/mach-shmobile/board-lager.c:35:41: fatal error: > linux/platform_data/rcar-du.h: No such file

[PATCH 4/4] drm/msm/hdmi: don't call clk_round_rate to check hdmi pclk for MDP5

clock driver can support dynamic rate settings for HDMI pixelclock, so don't need to use clk_round_rate to check if the clockrate for specific mode is supported therefore more display modes can be supported. Signed-off-by: Jilai Wang --- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 9 -

[PATCH 3/4] drm/msm/hdmi: rework HDMI IRQ hanlder

Disable the HPD interrupt when acking it, to avoid spurious interrupt. Signed-off-by: Jilai Wang --- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c

[PATCH 2/4] drm/msm/hdmi: enable regulators before clocks to avoid warnings

HPD regulators need to be enabled before clocks, otherwise clock driver will report warning. Signed-off-by: Jilai Wang --- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 45 +-- 1 file changed, 18 insertions(+), 27 deletions(-) diff --git

[PATCH 1/4] drm/msm/hdmi: use HPD interrupt to track connector status change

HPD interrupt can be tracked for each connector, so don't need to poll the connector status for state change. Signed-off-by: Jilai Wang --- drivers/gpu/drm/msm/hdmi/hdmi_connector.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/gpu/drm/msm/hdmi/hdmi_connector.c

[PATCH RESEND v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

Hi Boris, Thank you for the patch. On Monday 01 December 2014 09:42:15 Boris Brezillon wrote: > Add bus_formats and num_bus_formats fields and > drm_display_info_set_bus_formats helper function to specify the bus > formats supported by a given display. > > This information can be used by

[PATCH 2/3] hdmi: added unpack and logging functions for InfoFrames

Hi Thierry, Thanks for the review, see my comments below. On 12/01/2014 02:15 PM, Thierry Reding wrote: > On Fri, Nov 28, 2014 at 03:50:50PM +0100, Hans Verkuil wrote: >> From: Martin Bugge >> >> When receiving video it is very useful to be able to unpack the InfoFrames. >> Logging is useful as

[PATCH v2] drm/cirrus: fix leaky driver load error handling

On Mon, Dec 1, 2014 at 2:15 PM, Zach Reizner wrote: > Before this patch, cirrus_mm_init could have failed while > cirrus_modeset_init succeeded and the driver would have reported overall > success on load. This patch causes cirrus_driver_load to return on the > first error encountered. > >

[PATCH] drm/i915 Trouble with minimum brightness

On Mon, 01 Dec 2014, Jay Aurabind wrote: >> Please file a new bug at [1], reference this mail, and attach >> /sys/kernel/debug/dri/0/i915_opregion. > > Thank you for the response. But the file you mentioned to attach seems to be > a binary file, because I'm getting lot of junk characters. Is this

[PATCH v2] drm/cirrus: fix leaky driver load error handling

Before this patch, cirrus_mm_init could have failed while cirrus_modeset_init succeeded and the driver would have reported overall success on load. This patch causes cirrus_driver_load to return on the first error encountered. Reviewed-by: Stéphane Marchesin Signed-off-by: Zach Reizner ---

[PATCH 2/3] hdmi: added unpack and logging functions for InfoFrames

* @frame of the HDMI Auxiliary Video (AVI) information frame. > + * Also verifies the checksum as required by section 5.3.5 of the HDMI 1.4 > specification. > + * > + * Returns 0 on success or a negative error code on failure. > + */ > +static int hdmi_avi_infoframe_unpack(void *buffer, struct hdmi_avi_infoframe > *frame) I'm on the fence about ordering of arguments here. I think I'd slightly prefer the infoframe to be the first, to make the API more object- oriented. > +{ > + u8 *ptr = buffer; > + int ret; > + > + if (ptr[0] != HDMI_INFOFRAME_TYPE_AVI || > + ptr[1] != 2 || > + ptr[2] != HDMI_AVI_INFOFRAME_SIZE) { > + return -EINVAL; > + } No need for the braces. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/b49d69f2/attachment.sig>

build regression with "rcar-du: Remove platform data support"

Hi Laurent, linux-next has failed to build with lager_defconfig and marzen_defconfig for a while, with this error: arch/arm/mach-shmobile/board-lager.c:35:41: fatal error: linux/platform_data/rcar-du.h: No such file or directory #include which is evidently the result of your patch commit

[PATCH 2/4] drm/msm/hdmi: enable regulators before clocks to avoid warnings

Hi Jilai, On 11/26/2014 03:16 PM, Jilai Wang wrote: > HPD regulators need to be enabled before clocks, otherwise clock > driver will report warning. > > Change-Id: Ieca41722ae3b15873e6290649a21bbd13e1a4278 Nit: The upstream preference is to omit Change-Id lines. You should be able to move

[Bug 83998] Oopses on R9270X using UVD since radeon/uvd: use PIPE_USAGE_STAGING for msg buffers

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

[PATCH libdrm] drm: Avoid out of bound write in drmOpenByName()

In the fallback code that looks for devices in /proc, the read() may return with -1 in case of error (interruption from a signal for instance). We'll then happily write '\0' to buf[-2]. As we didn't really care about the signal interruption before, I kept it the same way, just making sure that

[PATCH RESEND v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

Hi Laurent, On Mon, 01 Dec 2014 15:00:15 +0200 Laurent Pinchart wrote: > Hi Boris, > > Thank you for the patch. > > On Monday 01 December 2014 09:42:15 Boris Brezillon wrote: > > Add bus_formats and num_bus_formats fields and > > drm_display_info_set_bus_formats helper function to specify the

[Bug 86832] [dota2][si] freezes up to 3 seconds when many/big display effects happen

TML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/b410079d/attachment.html>

[PATCH] drm/cirrus: fix leaky driver load error handling

On Mon, Nov 17, 2014 at 5:19 PM, Zach Reizner wrote: > Before this patch, cirrus_device_init could have failed while > cirrus_mm_init succeeded and the driver would have reported overall > success on load. This patch causes cirrus_device_init to return on > the first error encountered. > >

[PATCH V2] drm/exynos: Add DECON driver

Hi Ajay, On 28 November 2014 at 16:45, Ajay Kumar wrote: > This series is based on exynos-drm-next branch of Inki Dae's tree at: > git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git > > DECON(Display and Enhancement Controller) is the new IP > in exynos7 SOC for generating

[PATCH] drm: i2c: tda998x: Retry fetching the EDID if it fails first time.

On 11/29/14 10:41, Jean-Francois Moine wrote: > On Fri, 28 Nov 2014 09:02:39 + > Andrew Jackson wrote: > >>> It seems that your patch is deprecated by Laurent Pinchart's >>> [PATCH] drm: tda998x: Use drm_do_get_edid() >>>

[PATCH v13 07/12] drm: bridge/dw_hdmi: add support for multi-byte register width access

Am Freitag, den 28.11.2014, 17:43 +0800 schrieb Andy Yan: > Hi Zabel: > On 2014年11月27日 00:34, Philipp Zabel wrote: > > Am Mittwoch, den 26.11.2014, 21:32 +0800 schrieb Andy Yan: > >> On rockchip rk3288, only word(32-bit) accesses are > >> permitted for hdmi registers. Byte width accesses

[PATCH v14 05/12] drm: imx: imx-hdmi: move imx-hdmi to bridge/dw_hdmi

Hi Andy, Am Montag, den 01.12.2014, 19:24 +0800 schrieb Andy Yan: [...] > diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h > new file mode 100644 > index 000..1bbf3ca > --- /dev/null > +++ b/include/drm/bridge/dw_hdmi.h > @@ -0,0 +1,57 @@ > +/* > + * Copyright (C) 2011

[PATCH] drm/radeon: Hide cursor on CRTCs used by fbdev

On 28.11.2014 22:38, Daniel Vetter wrote: > On Fri, Nov 28, 2014 at 11:48:48AM +0900, Michel Dänzer wrote: >> From: Michel Dänzer >> >> Since we are now preserving the cursor across modesets, the cursor could >> be left over in console if e.g. X crashed. > > I'd add a fixme for this since if

[PATCH 1/3] hdmi: add new HDMI 2.0 defines

On 12/01/2014 12:03 PM, Thierry Reding wrote: > On Fri, Nov 28, 2014 at 03:50:49PM +0100, Hans Verkuil wrote: >> From: Hans Verkuil >> >> Add new Video InfoFrame colorspace information introduced in HDMI 2.0 >> and new Audio Coding Extension Types, also from HDMI 2.0. >> >> Signed-off-by: Hans

[PATCH 2/2] drm/panel: Add support for Giantplus GPG482739QS5 panel

Hi Thierry, just a gentle ping for those 2 patches. It would be nice if you could pick them up, so they can go into the next mergewindow. Regards, Lucas Am Mittwoch, den 19.11.2014, 10:29 +0100 schrieb Lucas Stach: > From: Philipp Zabel > > This patch adds support for the GiantPlus

[PATCH 1/3] hdmi: add new HDMI 2.0 defines

EG_HE_AAC_SURROUND, > + HDMI_AUDIO_CODING_TYPE_EXT_MPEG_AAC_LC_SURROUND = 10, I think the last two should be MPEG4_{HE_AAC,AAC}_SURROUND, and with that fixed: Reviewed-by: Thierry Reding -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/9aa18dcc/attachment.sig>

[Bug 83461] hdmi screen flicker/unusable

https://bugzilla.kernel.org/show_bug.cgi?id=83461 --- Comment #27 from Christian König --- Created attachment 159331 --> https://bugzilla.kernel.org/attachment.cgi?id=159331=edit Testing patch. (In reply to kb from comment #26) > (In reply to Christian König from comment #25) > > You could

[PATCH 2/3] drm/panel: add s6e63j0x03 LCD Panel driver

el); > + if (ret < 0) > + goto err_unregister_backlight; > + > + ret = mipi_dsi_attach(dsi); > + if (ret < 0) > + goto err_remove_panel; > + > + return ret; > + > +err_remove_panel: > + drm_panel_remove(>panel); > + > +err_unregister_backlight: No need for the err_ prefix here. > + backlight_device_unregister(ctx->bl_dev); > + > + return ret; > +} > + > +static int s6e63j0x03_remove(struct mipi_dsi_device *dsi) > +{ > + struct s6e63j0x03 *ctx = mipi_dsi_get_drvdata(dsi); > + > + mipi_dsi_detach(dsi); > + drm_panel_remove(>panel); > + > + backlight_device_unregister(ctx->bl_dev); > + > + return 0; > +} > + > +static struct of_device_id s6e63j0x03_of_match[] = { static const please. > + { .compatible = "samsung,s6e63j0x03" }, > + { } > +}; > +MODULE_DEVICE_TABLE(of, s6e63j0x03_of_match); > + > +static struct mipi_dsi_driver s6e63j0x03_driver = { > + .probe = s6e63j0x03_probe, > + .remove = s6e63j0x03_remove, > + .driver = { > + .name = "panel_s6e63j0x03", > + .owner = THIS_MODULE, It is no longer necessary to specify this explicitly. > + .of_match_table = s6e63j0x03_of_match, > + }, > +}; > +module_mipi_dsi_driver(s6e63j0x03_driver); You're missing MODULE_AUTHOR, MODULE_DESCRIPTION and MODULE_LICENSE here. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141201/56994439/attachment.sig>

[RFC] drm/ttm: dma: Fixes for 32-bit and 64-bit ARM

On Wed, Nov 12, 2014 at 06:03:49PM +0100, Arnd Bergmann wrote: > On Wednesday 12 November 2014 09:18:59 Konrad Rzeszutek Wilk wrote: > > On Wed, Nov 12, 2014 at 01:39:05PM +0100, Thierry Reding wrote: > > > From: Thierry Reding > > > > > > dma_alloc_coherent() returns a kernel virtual address

[PATCH] drm/i915 Trouble with minimum brightness

On Fri, 28 Nov 2014, Jay Aurabind wrote: > Hello all, > > I notice that some activity has been going on with the minimum value > of display brightness recently (e1c412e7575). > > But the minimum value thats currently chosen is not at all acceptable > for my eyes. My display is working perfectly

RFC on upstreaming of a Mediatek DRM modesetting driver

On Mon, Dec 1, 2014 at 5:01 AM, Frank Binns wrote: > Hi, > > We are currently in negotiations with one of our customers (Mediatek) on a > strategy that will allow them to push a DRM modesetting driver into the > upstream kernel. We are writing to get people's opinions and feedback on our >

[PATCH 1/1] GPU-DRM-MSM: Deletion of unnecessary checks before two function calls

btw, I have these two queued up on msm-next, thanks BR, -R On Tue, Nov 25, 2014 at 8:33 AM, SF Markus Elfring wrote: > From: Markus Elfring > Date: Tue, 25 Nov 2014 14:30:28 +0100 > > The functions framebuffer_release() and vunmap() perform also input > parameter validation. Thus the test

[PATCH 1/1] GPU-DRM-MSM: Deletion of unnecessary checks before two function calls

On Mon, Dec 1, 2014 at 11:04 AM, Thierry Reding wrote: > On Tue, Nov 25, 2014 at 02:33:53PM +0100, SF Markus Elfring wrote: >> From: Markus Elfring >> Date: Tue, 25 Nov 2014 14:30:28 +0100 >> >> The functions framebuffer_release() and vunmap() perform also input >> parameter validation. Thus the

[PATCH 0/2] drm: tda998x: Fix a couple of problems

On Sat, Nov 29, 2014 at 09:12:51AM +0100, Jean-Francois Moine wrote: > 1) > The HDMI registers of the tda998x chips are accessed by pages. > As these HDMI registers may be accessed from different tasks > (video, irq/workqueue, and soon audio), the page register setting > must be protected. > > 2)

RFC on upstreaming of a Mediatek DRM modesetting driver

On Mon, Dec 01, 2014 at 10:01:37AM +, Frank Binns wrote: > Hi, > > We are currently in negotiations with one of our customers (Mediatek) on a > strategy that will allow them to push a DRM modesetting driver into the > upstream kernel. We are writing to get people's opinions and feedback on >

RFC on upstreaming of a Mediatek DRM modesetting driver

Hi, We are currently in negotiations with one of our customers (Mediatek) on a strategy that will allow them to push a DRM modesetting driver into the upstream kernel. We are writing to get people's opinions and feedback on our proposed approach. Currently, our driver is structured in such a

[PATCH RESEND v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

Add bus_formats and num_bus_formats fields and drm_display_info_set_bus_formats helper function to specify the bus formats supported by a given display. This information can be used by display controller drivers to configure the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw

[Intel-gfx] [RFC PATCH v3 1/4] drm/i915: add i915_ved.c to setup bridge for VED

On Mon, Dec 01, 2014 at 03:04:27AM +, Cheng, Yao wrote: > > -Original Message- > > From: Beckett, Robert > > Sent: Saturday, November 29, 2014 0:59 > > To: Cheng, Yao; intel-gfx at lists.freedesktop.org; dri- > > devel at lists.freedesktop.org; daniel.vetter at ffwll.ch; Kelley, Sean

[PATCH v4 3/3] drm: panel: simple-panel: add bus format information for foxlink panel

Foxlink's fl500wvr00-a0t supports RGB888 format. Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panel/panel-simple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 66838a5..695f406 100644 ---

[PATCH v4 2/3] drm: panel: simple-panel: add support for bus_format retrieval

Provide a way to specify panel requirement in terms of supported media bus format (particularly useful for panels connected to an RGB or LVDS bus). Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panel/panel-simple.c | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

Add bus_formats and num_bus_formats fields and drm_display_info_set_bus_formats helper function to specify the bus formats supported by a given display. This information can be used by display controller drivers to configure the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw

[PATCH v4 0/3] drm: describe display bus format

Hello, This series makes use of the MEDIA_BUS_FMT definition to describe how the data are transmitted to the display. This will allow drivers to configure their output display bus according to the display capabilities. For example some display controllers support DPI (or raw RGB) connectors and

[PATCH v4 3/3] drm: panel: simple-panel: add bus format information for foxlink panel

Foxlink's fl500wvr00-a0t supports RGB888 format. Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panel/panel-simple.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index 66838a5..695f406 100644 ---

[PATCH v4 2/3] drm: panel: simple-panel: add support for bus_format retrieval

Provide a way to specify panel requirement in terms of supported media bus format (particularly useful for panels connected to an RGB or LVDS bus). Signed-off-by: Boris Brezillon --- drivers/gpu/drm/panel/panel-simple.c | 5 + 1 file changed, 5 insertions(+) diff --git

[PATCH v4 1/3] drm: add bus_formats and num_bus_formats fields to drm_display_info

Add bus_formats and num_bus_formats fields and drm_display_info_set_bus_formats helper function to specify the bus formats supported by a given display. This information can be used by display controller drivers to configure the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw

[PATCH v4 0/3] drm: describe display bus format

Hello, This series makes use of the MEDIA_BUS_FMT definition to describe how the data are transmitted to the display. This will allow drivers to configure their output display bus according to the display capabilities. For example some display controllers support DPI (or raw RGB) connectors and

[Bug 88541] Resume of HDMI port fails

https://bugzilla.kernel.org/show_bug.cgi?id=88541 Aaron Lu changed: What|Removed |Added CC||aaron.lu at intel.com

RFC on upstreaming of a Mediatek DRM modesetting driver

each display block like it's currently done > with all the armsoc stuff on android is imo completely no-go. > > Note that the component interface is completely irrelevant wrt the > interface you expose to userspace. It's just an driver-internal helper > library useful in certain situation.

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst

into abbreviations :) -- 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/20141201/2aa5b68f/attachment.html>

[Bug 86864] [rv6xx] RADEON_FLAG_GTT_WC causes GPU to reset when playing Second Life / other games

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

[Bug 86832] [dota2][si] freezes up to 3 seconds when many/big display effects happen

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141201/a2496892/attachment.html>

[Bug 86864] [rv6xx] RADEON_FLAG_GTT_WC causes GPU to reset when playing Second Life / other games

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/20141201/329c8ff1/attachment.html>

[Bug 86011] [drm] "Memory manager not clean during takedown" after vga-switcheroo turn off nvidia card

https://bugzilla.kernel.org/show_bug.cgi?id=86011 --- Comment #5 from Joaquín Aramendía --- Created attachment 159291 --> https://bugzilla.kernel.org/attachment.cgi?id=159291=edit fix for runtime power management in nouveau I made this patch that fixed the issue for me. Applies on top of

[Bug 86864] [rv6xx] RADEON_FLAG_GTT_WC causes GPU to reset when playing Second Life / other games

p () from /lib64/libpthread.so.0 * 1Thread 0x7270aa00 (LWP 1579) "do-not-directly" 0x0037a640f8fd in nanosleep () from /lib64/libpthread.so.0 -- 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/20141201/a92bc6e5/attachment-0001.html>

[RFC] drm: Start documenting userspace ABI

On Wednesday 19 November 2014 14:23:47 Daniel Vetter wrote: > On Tue, Nov 18, 2014 at 04:24:39PM +0100, Thierry Reding wrote: > > On Tue, Nov 18, 2014 at 04:05:08PM +0100, David Herrmann wrote: > > > On Tue, Nov 18, 2014 at 3:43 PM, Thierry Reding wrote: > > > > On Tue, Nov 18, 2014 at 03:27:27PM

[RFC PATCH v3 3/4] ipvr: user mode helper for ipvr drm driver

Add Jon/Bob/Raf for detail review. > -Original Message- > From: Cheng, Yao > Sent: Saturday, November 22, 2014 3:09 > To: intel-gfx at lists.freedesktop.org; dri-devel at lists.freedesktop.org; > daniel.vetter at ffwll.ch; Kelley, Sean V; Chehab, John > Cc: Jiang, Fei; dh.herrmann at

  1   2   >