[Bug 91896] AMDGPU Fiji: only getting 1080i on DP

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/20150907/3f4fc3fc/attachment.html>

[PATCH libdrm] tests: Add -lm to LDADD for dristat

From: Michel Dänzer Fixes build failure due to unresolved log2. Signed-off-by: Michel Dänzer --- tests/Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/Makefile.am b/tests/Makefile.am index 9a2d932..a511d28 100644 --- a/tests/Makefile.am +++

[PATCH 3/3] drm: Make drm_av_sync_delay() 'mode' argument const

From: Ville Syrjälä drm_av_sync_delay() doesn't change the passed in mode, so make it const. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 2 +- include/drm/drm_edid.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH 2/3] drm: Remove the 'mode' argument from drm_select_eld()

From: Ville Syrjälä drm_select_eld() doesn't look at the passed in mode, so don't pass it in. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 4 +--- drivers/gpu/drm/i915/intel_audio.c | 2 +- include/drm/drm_edid.h | 3 +--

[PATCH 1/3] drm: Make some modes const when iterating through them

From: Ville Syrjälä valid_inferred_mode() don't change the modes over which it iterates, so make the iterator const. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_edid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] drm/mgag200: fix memory leak

If drm_fb_helper_alloc_fbi() fails then we were directly returning without freeing sysram. Also if drm_fb_helper_alloc_fbi() succeeds but mgag200_framebuffer_init() fails then we were not releasing sysram and we were not releasing fbi helper also. Signed-off-by: Sudip Mukherjee ---

[RFC 0/2] drm/dsi: DSI for devices with different control bus

Thierry, On 08/21/2015 11:39 AM, Archit Taneja wrote: > > > On 08/20/2015 05:18 PM, Thierry Reding wrote: >> On Thu, Aug 20, 2015 at 09:46:14AM +0530, Archit Taneja wrote: >>> Hi Thierry, Lucas, >>> >>> >>> On 08/19/2015 08:32 PM, Thierry Reding wrote: On Wed, Aug 19, 2015 at 04:52:24PM

similar files amd vs radeon

I executed a clone detection tool* on drivers source code and I found that there are similar files between drivers/gpu/drm/amd/ and drivers/gpu/drm/radeon, but also inside each of theses folders. Some examples: drivers/gpu/drm/amd/amdgpu/dce_v11_0.c,drivers/gpu/drm/amd/amdgpu/dce_v10_0.c

[PATCH] scripts/kernel-doc: Improve Markdown results

On 09/04/2015 05:39 PM, Jonathan Corbet wrote: > On Fri, 4 Sep 2015 14:53:34 -0300 > Danilo Cesar Lemes de Paula wrote: > >> In the last few days I sent three features: >> Markdown support (patch series 1) >> Cross-reference hyperlink support (patch series 1) >> in-struct-body documentation

[PATCH v2 5/5] drm/i2c: adv7511: Add dsi driver for adv7533

Add a separate mipi_dsi_driver for adv7533. In the case of this chip, both the i2c and dsi drivers will operate together. Both the drivers are expected to use the same per-device driver data struct. The i2c driver takes the responsibility of allocating the struct, and the dsi device gets a

[PATCH v2 4/5] drm/i2c: adv7511: Add drm_bridge/connector for ADV7533

Create bridge and connector helper functions. These internally refer to the ADV75xx helper functions. The driver registers a drm_bridge object during probe. The bridge, in turn registers a HDMI connector when a user attaches the bridge. Therefore, when the device type is ADV7533, we create

[PATCH v2 3/5] drm/i2c: adv7511: Refactor encoder slave functions

ADV7511 is represented as an i2c drm slave encoder device. ADV7533, on the other hand, is going be a normal i2c client device creating bridge and connector entities. Move the code in encoder slave functions to generate helpers that are agnostic to the drm object type. These helpers will later

[PATCH v2 2/5] drm/i2c: adv7511: Initial support for adv7533

From: Lars-Peter Clausen ADV7533 is a DSI to HDMI encoder chip. It is a derivative of ADV7511, with additional blocks to translate input DSI data to parallel RGB data. Besides the ADV7511 i2c register map, it has additional registers that require to be configured to activate the

[PATCH v2 1/5] drm/i2c: adv7511: Fix mutex deadlock when interrupts are disabled

When the adv7511 i2c client doesn't have an interrupt line, we observe a deadlock on caused by trying to lock drm device's mode_config.mutex twice in the same context. Here is the sequence that causes it: ioctl DRM_IOCTL_MODE_GETCONNECTOR from userspace drm_mode_getconnector (acquires

[PATCH v2 0/5] drm/i2c: adv7511: ADV7533 support

ADV7533 is a DSI to HDMI encoder chip. It's like ADV7511, but with an additional DSI RX block that takes in DSI video mode output. This series adds support for ADV7533. Unlike ADV7511 that's modelled as a drm i2c slave encoder, ADV7533 is a drm_bridge object. The bridge ops further create a HDMI

[PATCH 6/6] scripts/kernel-doc: Processing -nofunc for functions only

Docproc process EXPORT_SYMBOL(f1) macro and uses -nofunc f1 to avoid duplicated documentation in the next call. It works for most of the cases, but there are some specific situations where a struct has the same name of an already-exported function. Current kernel-doc behavior ignores those

[PATCH 5/6] scripts/kernel-doc: Improve Markdown results

Using pandoc as the Markdown engine cause some minor side effects as pandoc includes main tags for almost everything. Original Markdown support approach removes those main tags, but it caused some inconsistencies when that tag is not the main one, like: .. ... As kernel-doc was already

[PATCH 4/6] drm/doc: Fixing xml documentation warning

"/**" should be used for kernel-doc documentation only. It causes a warning with the new "in struct body" format. Signed-off-by: Danilo Cesar Lemes de Paula Cc: Randy Dunlap Cc: Daniel Vetter Cc: Laurent Pinchart Cc: Jonathan Corbet Cc: Herbert Xu Cc: Stephan Mueller Cc: Michal Marek Cc:

[PATCH 3/6] drm/doc: Convert to markdown

DRM Docbook is now Markdown ready. This means its doc is able to use markdown text on it. * Documentation/DocBook/drm.tmpl: Contains a table duplicated from drivers/gpu/drm/i915/i915_reg.h. This is not needed anymore * drivers/gpu/drm/drm_modeset_lock.c: had a code example that used to look

[PATCH 2/6] scripts/kernel-doc: Adding infrastructure for markdown support

Markdown support is given by calling an external tool, pandoc, for all highlighted text on kernel-doc. Pandoc converts Markdown text to proper Docbook tags, which will be later translated to pdf, html or other targets. This adds the capability of adding human-readle text highlight (bold,

[PATCH 1/6] scripts/kernel-doc: Replacing highlights hash by an array

The "highlight" code is very sensible to the order of the hash keys, but the order of the keys cannot be predicted. It generates faulty DocBook entries like: - @device_for_each_child Sorting the result is not enough some times (as it's deterministic but we can't control it). We should use

[PATCH 0/6] scripts/kernel-doc: Kernel-doc improvements

The following series contains: * kernel-doc: markdown support and improvements. * Fixing kernel-doc highlights. * Improve doc support for functions and structs with same name. * misc small fixes for drm docbook. Signed-off-by: Danilo Cesar Lemes de Paula Cc: Daniel Vetter Cc: Jonathan

[PATCH libdrm 2/2] xf86drmMode: smoke-test the atomic API

On Mon, Sep 07, 2015 at 10:53:06AM +0100, Emil Velikov wrote: > As going through the modetest patches for atomic support I've noticed > that if we pass NULL for the drmModeAtomicReqPtr argument we'll crash. > > So let's handle things appropriately if the user forgot to check the > return value of

[PATCH v4 0/22] On-demand device probing

On Mon, Sep 7, 2015 at 7:23 AM, Tomeu Vizoso wrote: > Hello, > > I have a problem with the panel on my Tegra Chromebook taking longer > than expected to be ready during boot (Stéphane Marchesin reported what > is basically the same issue in [0]), and have looked into ordered > probing as a

[PATCHv9 15/15] cobalt: add cec support

From: Hans Verkuil Add CEC support to the cobalt driver. Signed-off-by: Hans Verkuil --- drivers/media/pci/cobalt/Kconfig | 1 + drivers/media/pci/cobalt/cobalt-driver.c | 51 -- drivers/media/pci/cobalt/cobalt-driver.h | 2 +

[PATCHv9 14/15] cec: s5p-cec: Add s5p-cec driver

From: Kamil Debski Add CEC interface driver present in the Samsung Exynos range of SoCs. The following files were based on work by SangPil Moon: - exynos_hdmi_cec.h - exynos_hdmi_cecctl.c Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil ---

[PATCHv9 13/15] cec: adv7511: add cec support.

From: Hans Verkuil Add CEC support to the adv7511 driver. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- drivers/media/i2c/adv7511.c | 359

[PATCHv9 12/15] cec: adv7842: add cec support

From: Hans Verkuil Add CEC support to the adv7842 driver. Signed-off-by: Hans Verkuil --- drivers/media/i2c/adv7842.c | 267 +--- 1 file changed, 250 insertions(+), 17 deletions(-) diff --git a/drivers/media/i2c/adv7842.c

[PATCHv9 11/15] cec: adv7604: add cec support.

From: Hans Verkuil Add CEC support to the adv7604 driver. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged changes from CEC Updates commit by Hans Verkuil] [k.debski at samsung.com: add missing methods cec/io_write_and_or] [k.debski at samsung.com: change

[PATCHv9 10/15] v4l2-subdev: add HDMI CEC ops

From: Hans Verkuil Add CEC callbacks to the v4l2_subdev_video_ops. These are the low-level CEC ops that subdevs that support CEC have to implement. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged changes from CEC Updates commit by Hans Verkuil]

[PATCHv9 09/15] DocBook/media: add CEC documentation

From: Hans Verkuil Add DocBook documentation for the CEC API. Signed-off-by: Hans Verkuil [k.debski at samsung.com: add documentation for passthrough mode] [k.debski at samsung.com: minor fixes and change of reserved field sizes] Signed-off-by: Kamil Debski

[PATCHv9 08/15] cec.txt: add CEC framework documentation

Document the new HDMI CEC framework. Signed-off-by: Hans Verkuil [k.debski at samsung.com: add DocBook documentation by Hans Verkuil, with Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- Documentation/cec.txt | 166 ++ 1 file

[PATCHv9 07/15] cec: add HDMI CEC framework

From: Hans Verkuil The added HDMI CEC framework provides a generic kernel interface for HDMI CEC devices. Signed-off-by: Hans Verkuil [k.debski at samsung.com: Merged CEC Updates commit by Hans Verkuil] [k.debski at samsung.com: Merged Update author commit by Hans

[PATCHv9 06/15] rc: Add HDMI CEC protocol handling

From: Kamil Debski Add handling of remote control events coming from the HDMI CEC bus. This patch includes a new keymap that maps values found in the CEC messages to the keys pressed and released. Also, a new protocol has been added to the core. Signed-off-by: Kamil Debski

[PATCHv9 05/15] HID: add HDMI CEC specific keycodes

From: Kamil Debski Add HDMI CEC specific keycodes to the keycodes definition. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil --- include/uapi/linux/input.h | 28 1 file changed, 28 insertions(+) diff --git a/include/uapi/linux/input.h

[PATCHv9 04/15] input.h: add BUS_CEC type

From: Hans Verkuil Inputs can come in over the HDMI CEC bus, so add a new type for this. Signed-off-by: Hans Verkuil Acked-by: Dmitry Torokhov --- include/uapi/linux/input.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/input.h

[PATCHv9 03/15] dts: exynos4412-odroid*: enable the HDMI CEC device

From: Kamil Debski Add a dts node entry and enable the HDMI CEC device present in the Exynos4 family of SoCs. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil Acked-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4210-universal_c210.dts | 4 1 file changed,

[PATCHv9 02/15] dts: exynos4: add node for the HDMI CEC device

From: Kamil Debski This patch adds HDMI CEC node specific to the Exynos4210/4x12 SoC series. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil Acked-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4.dtsi | 12 1 file changed, 12 insertions(+) diff

[PATCHv9 01/15] dts: exynos4*: add HDMI CEC pin definition to pinctrl

From: Kamil Debski Add pinctrl nodes for the HDMI CEC device to the Exynos4210 and Exynos4x12 SoCs. These are required by the HDMI CEC device. Signed-off-by: Kamil Debski Signed-off-by: Hans Verkuil Acked-by: Krzysztof Kozlowski --- arch/arm/boot/dts/exynos4210-pinctrl.dtsi

[PATCHv9 00/15] HDMI CEC framework

Hi all, The ninth version of this patchset addresses comments I received from Russell King. As far as I am concerned this version is code complete (but I said that before) and the only thing missing is that the cec.txt documentation is out-of-sync with the current implementation. So there will

[PATCH] virtio-gpu: fix compilation warnings

On Mi, 2015-09-02 at 12:30 +0300, Mike Rapoport wrote: > Update snprintf format in virtgpu_fence.c and virtgpu_debugfs.c to fix the > following compilation warnings: > > C [M] drivers/gpu/drm/virtio/virtgpu_fence.o > drivers/gpu/drm/virtio/virtgpu_fence.c: In function >

[Intel-gfx] [PATCH] libdrm: Add framebuffer modifiers uapi

On 08/03/2015 10:48 AM, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Sync up with new kernel features as per commits: > > e3eb3250d84ef97b766312345774367b6a310db8 > 93b81f5102a7cd270a305c2741b17c8d44bb0629 > b5ff6e1637b683d5996ae11ac29afe406c0bee90 > 8c4f83fb1e8bf317e894f62d17a63c32b7a6b75e

[git pull] drm for 4.3

On Fri, Sep 04, 2015 at 11:40:53PM +0100, Dave Airlie wrote: > > Hi Linus, > > This is the main pull request for the drm for 4.3. Nouveau is probably the > biggest > amount of changes in here, since it missed 4.2. Highlights below, along with > the usual > bunch of fixes. There are a

[PATCH v4 10/22] drm/tegra: Probe dpaux devices on demand

When looking up a dpaux device through its OF node, probe it if it hasn't already. The goal is to reduce deferred probes to a minimum, as it makes it very cumbersome to find out why a device failed to probe, and can introduce very big delays in when a critical device is probed. Signed-off-by:

[PATCH v4 09/22] drm: Probe panels on demand

When looking up a panel through its OF node, probe it if it hasn't already. The goal is to reduce deferred probes to a minimum, as it makes it very cumbersome to find out why a device failed to probe, and can introduce very big delays in when a critical device is probed. Signed-off-by: Tomeu

[PATCH v4 0/22] On-demand device probing

Hello, I have a problem with the panel on my Tegra Chromebook taking longer than expected to be ready during boot (Stéphane Marchesin reported what is basically the same issue in [0]), and have looked into ordered probing as a better way of solving this than moving nodes around in the DT or

[PATCH] gpu: host1x: Fix MLOCK's debug info

28.06.2015 22:27, Dmitry Osipenko пишет: > MLOCK's debug info, spewed on CDMA timeout, contains meaningless MLOCK > owner channel ID because HOST1X_SYNC_MLOCK_OWNER_CHID_F() returns shifted > value, while unshifted should be used. Fix it by changing '_F' to '_V'. > > Signed-off-by: Dmitry

[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150907/30abe69e/attachment-0001.sig>

[PATCH libdrm] xf86drm: remove makedev() hack/workaround

On 7 August 2015 at 17:39, Emil Velikov wrote: > Back when this was introduced commit 569da5a42eb(Merged glxmisc-3-0-0) > sys/sysmacros.h was used instead of the respecive headers (as per the > manual). > > We've been handling it correctly for a little while now - in Linux, BSD > and Solaris.

[PATCH libdrm 2/2] xf86drmMode: smoke-test the atomic API

As going through the modetest patches for atomic support I've noticed that if we pass NULL for the drmModeAtomicReqPtr argument we'll crash. So let's handle things appropriately if the user forgot to check the return value of drmModeAtomicAlloc and drmModeAtomicDuplicate or made a typo somewhere

[PATCH libdrm 1/2] automake: set --enable-valgrind during make distcheck

Signed-off-by: Emil Velikov --- Makefile.am | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index a7a0cca..ca41508 100644 --- a/Makefile.am +++ b/Makefile.am @@ -37,7 +37,8 @@ AM_DISTCHECK_CONFIGURE_FLAGS = \ --enable-tegra-experimental-api

[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

o if your variant doesn't have the HPD line, we're dealing with quirks within the same family of panels. That would make this some sort of quirk, and I'm not sure if there is a standard way for defining quirks in DT. Rob, do you know of any precedent for this? I suppose we could always add a variant-specific compatible string that would allow this quirk to be encoded in the driver, though I'm not sure if the model string in datasheets has enough detail to tell them apart. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150907/c2a060c9/attachment-0001.sig>

[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir

Hi Krzysztof, 在 09/07/2015 08:22 AM, Krzysztof Kozlowski 写道: > On 06.09.2015 16:49, Yakir Yang wrote: >> Hi Krzysztof, >> >> 在 09/04/2015 08:41 AM, Krzysztof Kozlowski 写道: >>> On 03.09.2015 14:30, Yakir Yang wrote: Hi Krzysztof, 在 09/03/2015 08:58 AM, Krzysztof

[PATCH v4 14/16] drm: bridge: analogix/dp: try force hpd after plug in lookup failed

for that panel lists HPD as pin 17. Also I used to have a setup with that panel and I distinctly remember hotplug working just fine. Perhaps this is an issue with a specific variant of the panel? Or perhaps this is indeed a problem with the cable that's connecting the panel to the board. It could be one of those cases where they left out the HPD conductor to save money. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150907/b3e2ffa1/attachment-0001.sig>

[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir

behave differently in this case. Gustavo has done a lot of work on cleaning up the Exynos driver lately, so perhaps you should sync up with him to see if this is something that he can integrate with his changes. If you can't reach an agreement and Exynos must keep the exact behaviour as it has now, then perhaps a better option would be to have the Analogix core driver not register the connector but rather leave that up to users of the helpers. Then you don't have to clutter the core driver with this type of platform-specific data. Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150907/096f8638/attachment-0001.sig>

[PATCH v4 11/16] drm: bridge: analogix/dp: add platform device type support

Hi Krzysztof, 在 09/07/2015 07:55 AM, Krzysztof Kozlowski 写道: > On 06.09.2015 13:07, Yakir Yang wrote: >> Hi Krzysztof, >> >> 在 09/04/2015 08:36 AM, Krzysztof Kozlowski 写道: >>> On 01.09.2015 15:07, Yakir Yang wrote: >>> >>> Empty commit message. Please explain here why you want to add

[PATCH v4 03/16] drm: bridge: analogix/dp: split exynos dp driver to bridge dir

On 06.09.2015 16:49, Yakir Yang wrote: > Hi Krzysztof, > > 在 09/04/2015 08:41 AM, Krzysztof Kozlowski 写道: >> On 03.09.2015 14:30, Yakir Yang wrote: >>> Hi Krzysztof, >>> >>> 在 09/03/2015 08:58 AM, Krzysztof Kozlowski 写道: On 01.09.2015 14:49, Yakir Yang wrote: > Split the dp

[PATCH v4 11/16] drm: bridge: analogix/dp: add platform device type support

On 06.09.2015 13:07, Yakir Yang wrote: > Hi Krzysztof, > > 在 09/04/2015 08:36 AM, Krzysztof Kozlowski 写道: >> On 01.09.2015 15:07, Yakir Yang wrote: >> >> Empty commit message. Please explain here why you want to add platform >> device type support. >> >> Actually the title is confusing. You