mx6 hdmi resolution behaviour

On Tue, Jun 23, 2015 at 09:58:37PM +0100, Russell King - ARM Linux wrote: > On Tue, Jun 23, 2015 at 05:48:51PM -0300, Fabio Estevam wrote: > > On Tue, Jun 23, 2015 at 5:41 PM, Russell King - ARM Linux > > wrote: > > > > > I've just tried this (the HBi1 was booted previously with the HDMI socket >

[PATCH 11/11] drm: Roll out drm_for_each_{plane,crtc,encoder}

Remaining manual work in the drm core&helpers. Nothing special here, no surprises. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_crtc.c | 26 ++ drivers/gpu/drm/drm_crtc_helper.c | 2 +- drivers/gpu/drm/drm_fb_cma_helper.c | 2 +- drivers/gpu/drm/drm_m

[PATCH 10/11] drm: Roll out drm_for_each_connector more

Now that we also grab the connection_mutex and so fixed the race with atomic modeset we can use the iterator there too. The other special case is drm_connector_unplug_all which would have a locking inversion with the sysfs store/show functions if we'd grab the mode_config.mutex around the unplug.

[PATCH 09/11] drm: Amend connector/encoder list locking rules

Now that dp mst hotplug takes all locks we can amend the locking rules for the iterators. This is needed before we can roll these out in the atomic code to avoid getting burried in WARNINGs. Signed-off-by: Daniel Vetter --- include/drm/drm_crtc.h | 6 -- 1 file changed, 4 insertions(+), 2 de

[PATCH 08/11] drm/i915: Take all modeset locks for DP MST hotplug

While auditing various users of the connector/encoder lists I realized that the atomic code is a very prolific user of them. And it only ever grabs the mode_config->connection_mutex, but not the mode_config->mutex like all the other code walking encoder/connector lists. The problem is that we can'

[PATCH 07/11] drm: Check locking in drm_for_each_fb

Ever since framebuffers are reference counted we have a special lock for the global fb list. Make sure users of that list do hold that lock when using the new iterators. Signed-off-by: Daniel Vetter --- include/drm/drm_crtc.h | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git

[PATCH 06/11] drm/i915: Use drm_for_each_fb in i915_debugfs.c

Just so I have a user for this macro. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_debugfs.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index c49fe2afa223..6db920c913ee 100644 ---

[PATCH 05/11] drm: Check locking in drm_for_each_encoder/connector

Because of DP MST encoders/connectors can now be hotplugged and we must hold the right lock when walking the encoder/connector lists. Enforce this by checking the locking in our shiny new list walking macros. Signed-off-by: Daniel Vetter --- include/drm/drm_crtc.h | 12 ++-- 1 file chang

[PATCH 04/11] drm/fbdev-helper: Grab mode_config.mutex in drm_fb_helper_single_add_all_connectors

This is now truly only duct-tape to keep locking checks happy since calling this function when hpd or polling are already enabled is a bug. The fbdev helper can't cope with hotplug changes yet at this point, only after that. Otoh a bit more robustness in this function can't hurt, and with this fbd

[PATCH 03/11] drm/probe-helper: Grab mode_config.mutex in poll_init/enable

So on first looks this seems superflous since drivers should ensure correct ordering to not make this a problem. Otoh ordering constraints between hdp, fbdev load and enabling polling are already tricky on some hardware and it helps to be more robust. But the real goal is to just shut up a locking

[PATCH 02/11] drm: Add modeset object iterators

And roll them out across drm_* files. The point here isn't code prettification (it helps with that too) but that some of these lists aren't static any more. And having macros will gives us a convenient place to put locking checks into. I didn't add an iterator for props since that's only used by a

[PATCH 01/11] drm: Simplify drm_for_each_legacy_plane arguments

No need to pass the planelist when everyone just uses dev->mode_config.plane_list anyway. I want to add a pile more of iterators with unified (obj, dev) arguments. This is just prep. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/intel_pm.c | 2 +- drivers/gpu/drm/shmobile/shmo

[PATCH 00/11] [RFC] drm_for_each_* macros and list locking

Hi all, Dave&I have been discussing connector hotplug and unplugging around DP MST and if there's one thing that's clear it's that we don't even really know where all the problems are. Hence first step is to figure that out. One of the bigger items is walking the encoder/connector lists without ap

[PATCH 1/5] drm/omap: return error if dma_alloc_writecombine fails

Hi Tomi, On Tuesday 23 June 2015 11:18:16 Tomi Valkeinen wrote: > On 18/06/15 17:27, Laurent Pinchart wrote: > > On Thursday 18 June 2015 13:10:35 Tomi Valkeinen wrote: > >> On a platform with no TILER (e.g. omap3, am43xx), when the user wants to > >> allocate buffer with flag OMAP_BO_SCANOUT, the

[PATCH] drm: rcar-du: Remove obsolete rcar-du-r8a779x platform_device_id entries

Hi Geert, Thank you for the patch. On Tuesday 23 June 2015 14:58:52 Geert Uytterhoeven wrote: > Since commit a483dcbfa21f919c ("ARM: shmobile: lager: Remove legacy > board support"), R-Car Gen2 SoCs are only supported in generic DT-only > ARM multi-platform builds. The driver doesn't need to mat

mx6 hdmi resolution behaviour

On Tue, Jun 23, 2015 at 05:48:51PM -0300, Fabio Estevam wrote: > On Tue, Jun 23, 2015 at 5:41 PM, Russell King - ARM Linux > wrote: > > > I've just tried this (the HBi1 was booted previously with the HDMI socket > > disconnected). Just now, I turned the TV on, and then connected it to > > the HD

mx6 hdmi resolution behaviour

On Tue, Jun 23, 2015 at 01:52:50PM -0300, Fabio Estevam wrote: > On Tue, Jun 23, 2015 at 1:44 PM, Russell King - ARM Linux > wrote: > > > If you have no connected connectors, then you get 1024x768: > > > > imx-drm display-subsystem: No connectors reported connected with modes > > [drm] Cannot fin

mx6 hdmi resolution behaviour

On Tue, Jun 23, 2015 at 5:58 PM, Russell King - ARM Linux wrote: >> That's the point that makes me confused: shouldn't it report a higher >> resolution like 1080p? > > No - it won't go higher than the initial mode that was set. See > drm_fb_helper_hotplug_event(): > > max_width = fb_help

[PATCH 23/23] drm/exynos: remove struct exynos_drm_encoder layer

From: Gustavo Padovan struct exynos_drm_encoder was justing wrapping struct drm_encoder, it had only a drm_encoder member and the internal exynos_drm_encoders ops that was directly mapped to the drm_encoder helper funcs. So now exynos DRM uses struct drm_encoder directly, this removes completely

[PATCH 22/23] drm/exynos: fold encoder setup into exynos_drm_load()

From: Gustavo Padovan As we are removing the exynos encoder move the encoder setup operation directly inside the exynos_drm_load() Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_drv.c | 12 ++-- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 13 - d

[PATCH 21/23] drm/exynos: remove exynos_drm_create_enc_conn()

From: Gustavo Padovan This functions was just hiding the encoder and connector creation in a way that was less clean than if we get rid of it. For example, exynos_encoder ops had .create_connector() defined only because we were handing off the encoder and connector creation to exynos_drm_create_e

[PATCH 20/23] drm/exynos: remove exynos_encoder's .commit() op

From: Gustavo Padovan .commit() is not used anymore, Exynos encoders now follow the .enable()/.disable() semantics from drm atomic core, so remove this callback. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 -- drivers/gpu/drm/exynos/exynos_drm_encoder.c |

[PATCH 19/23] drm/exynos: remove extra call to exynos_dp_commit()

From: Gustavo Padovan exynos_dp_commit() was getting called twice by exynos encoder core, once inside the .enable() call and another time by .commit() itself. The remove of the second call caused the wake of a bug, the operations orders inside exynos_dp_commit was wrong and we had to move exynos

[PATCH 18/23] drm/exynos: remove extra call to hdmi_commit()

From: Gustavo Padovan hdmi_commit() was getting called twice by exynos encoder core, once inside the .enable() call and another time by .commit() itself. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_hdmi.c | 17 + 1 file changed, 1 insertion(+), 16 deletions

[PATCH 17/23] drm/exynos: remove struct exynos_drm_display

From: Gustavo Padovan This struct was just representing encoder information, it was a member of struct exynos_drm_encoder, so any code trying to access encoder data would have to go through the encoder struct, get the display struct and then get the data it want. During this patchset we also rea

[PATCH 16/23] drm/exynos: simplify calculation of possible CRTCs

From: Gustavo Padovan All CRTCs can only be LCD, HDMI or VIDI, so basically all CRTCs will be a possible CRTCs. This patch removes an extra function with switch that was only checking if the CRTC type was one of those three above. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exyno

[PATCH 15/23] drm/exynos: remove unused .remove() and .check_mode() ops from display

From: Gustavo Padovan These two display_ops are not used anywhere, remove them. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_drv.h | 5 - 1 file changed, 5 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h b/drivers/gpu/drm/exynos/exynos_drm_drv.h

[PATCH 14/23] drm/exynos: remove wrappers for phy_power_{on,off}

From: Gustavo Padovan phy_power_on() and phy_power_off() already checks for NULL pointer. This patch removes the wrappers exynos_dp_phy_init() and exynos_dp_phy_exit() since the only think they were doing was a check for NULL phy. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exyno

[PATCH 13/23] drm/exynos: split display's .dpms() into .enable() and .disable()

From: Gustavo Padovan The DRM Core doesn't have a dpms() operation anymore, everything now is enable() or disable(). Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_dp_core.c | 37 drivers/gpu/drm/exynos/exynos_drm_dpi.c | 36 drivers/

[PATCH 12/23] drm/exynos: don't track enabled state at exynos_crtc

From: Gustavo Padovan struct drm_crtc already stores the enabled state of the crtc thus we don't need to replicate enabled in exynos_drm_crtc. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 16 drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 - 2 f

[PATCH 11/23] drm/exynos: unify exynos_drm_plane names with drm core

From: Gustavo Padovan Rename crtc_{widht,height} to crtc_{w,h} and src_{width,height} to src_{w,h} to make it similar to the atomic state names. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 14 +++--- drivers/gpu/drm/exynos/exynos_drm_drv.h| 16 ++

[PATCH 10/23] drm/exynos: remove unused fields from struct exynos_drm_plane

From: Gustavo Padovan Now after the move to use drm_plane_state directly struct drm_plane_state has many unused fields, along with others that weren't used before the plane state change. Thus remove them all. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_drv.h | 18 -

[PATCH 09/23] drm/exynos: use drm atomic state directly

From: Gustavo Padovan For some fields the use of struct exynos_drm_plane filled with data from the plane state just creates a source of duplicated information and overhead. Here we change the crtc drivers to access the plane state directly simplifying the code by not relying on a exynos internal

[PATCH 08/23] drm/exynos: pass struct exynos_drm_plane in update/enable

From: Gustavo Padovan We already have the plane pointer in before calling .update_plane() or disable_plane() so pass it directly to those calls avoiding a new conversion from zpos to struct exynos_drm_plane. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 22 +++

[PATCH 07/23] drm/exynos: rename win_commit/disable to atomic-like names

From: Gustavo Padovan Rename win_commit() helper to update_plane() and win_disable() to disable_plane(). Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 10 +- drivers/gpu/drm/exynos/exynos_drm_drv.h| 8 drivers/gpu/drm/exynos/exynos_drm_fi

[PATCH 06/23] drm/exynos: add atomic asynchronous commit

From: Gustavo Padovan The atomic modesetting interfaces supports async commits that should be implemented by the drivers. If drm core requests an async commit exynos_atomic_commit() will schedule a work task to run the update later. It also waits an update to finish before schedule a new one. S

[PATCH 05/23] drm/exynos: Kconfig: select DP if FIMD or DECON are selected

From: Gustavo Padovan DP is required if either FIMD or DECON are selected so select it automatically. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/Kconfig | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos

[PATCH 04/23] drm/exynos: remove duplicated check for suspend

From: Gustavo Padovan The same check is placed twice in fimd/decon_update_plane(), remove one of them. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 3 --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 --- 2 files changed, 6 deletions(-) diff --git a/driver

[PATCH 03/23] drm/exynos: use KMS version of DRM vblanks functions

From: Gustavo Padovan Get rid of legacy DRM vblank function that are less clear to use. The new ones basically requires only the crtc as parameters. It also clean ups exynos_drm_crtc_finish_pageflip() parameters as a consequence. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exyno

[PATCH 02/23] drm/exynos: calculate vrefresh instead of use a fixed value

From: Gustavo Padovan When mode's vrefresh is zero we should ask DRM core to calculate vrefresh for us so we can get the correct value instead of relying on fixed value defined in a macro. But if vrefresh is still zero we should fail the update. Suggested-by: Daniel Stone Signed-off-by: Gustavo

[PATCH 01/23] drm/exynos: pass the correct pipe number

From: Gustavo Padovan Instead of giving -1 to as arg to drm_send_vblank_event() pass the correct pipe number to it. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm

[PATCH 00/23] drm/exynos: atomic improvements + exynos_encoder removal

From: Gustavo Padovan Hi, This set improves exynos in a number of ways. The first five patches are general clean up/fixes. Patches 06 to 12 are improvements on top of the newly added atomic modesetting support. Patches 13-23 are a big journey to completely remove the internal exynos_drm_encode

[Intel-gfx] [v2 5/7] pwm: crc: Add Crystalcove (CRC) PWM driver

On Mon, Jun 22, 2015 at 4:46 PM, Varka Bhadram wrote: > Hi Shobhit Kumar, > > On 06/22/2015 04:24 PM, Shobhit Kumar wrote: > >> The Crystalcove PMIC provides three PWM signals and this driver exports >> one of them on the BYT platform which is used to control backlight for >> DSI panel. This is p

mx6 hdmi resolution behaviour

On Tue, Jun 23, 2015 at 5:41 PM, Russell King - ARM Linux wrote: > I've just tried this (the HBi1 was booted previously with the HDMI socket > disconnected). Just now, I turned the TV on, and then connected it to > the HDMI. Thanks for testing it. > The TV reported a resolution of 1024x768, an

mx6 hdmi resolution behaviour

On Tue, Jun 23, 2015 at 01:41:46PM -0300, Fabio Estevam wrote: > Hi, > > On a imx6q-cubox-i running 4.1 kernel I am getting 1920x1080 HDMI > resolution if I boot the board with the HDMI cable connected. > > If I boot it without the HDMI cable and then connect it afterwards, > the resolution goes

[PATCH] of: fix a build error to f_graph_get_endpoint_by_regs function

ephen Rothwellsfr at canb.auug.org.au -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/

[PATCH] drm/vgem: Set unique to "vgem"

Since there's only one global instance ever we don't need to have anything fancy. Stops a WARNING in the get_unique ioctl that the unique name isn't set. Cc: # 4.1+ only Reportedy-and-tested-by: Fabio Coatti Cc: Fabio Coatti Signed-off-by: Daniel Vetter --- drivers/gpu/drm/vgem/vgem_drv.c | 2

[PATCH] of: fix a build error to f_graph_get_endpoint_by_regs function

Hi Stephen, On 2015년 06월 23일 15:43, Stephen Rothwell wrote: > Hi Inki, > > On Tue, 23 Jun 2015 15:14:53 +0900 Inki Dae wrote: >> >> This patch fixes the below build error reported by Stephen, >> https://lkml.org/lkml/2015/6/22/665 > > Don't do this. Put the errors explicitly in the

[PATCH Resend] of: fix a build error to f_graph_get_endpoint_by_regs function

This patch fixes the below build error reported by Stephen, Stephen reported: After merging the drm-exynos tree, today's linux-next build (x86_64 allmodconfig) failed like this: drivers/media/i2c/adv7604.o: In function `of_graph_get_endpoint_by_regs': adv7604.c:(.text+0x5

Linux 4.1 WARNING in drm_ioctl.c

In data martedì 23 giugno 2015 15:29:41, Daniel Vetter ha scritto: > On Tue, Jun 23, 2015 at 12:46:09PM +0200, Fabio Coatti wrote: > > In data martedì 23 giugno 2015 11:48:47, Daniel Vetter ha scritto: > > > On Tue, Jun 23, 2015 at 08:27:13AM +0100, Daniel Stone wrote: > > > > Hi, > > > > > > >

[PATCH] drm: Always enable atomic API

On Tue, Jun 23, 2015 at 02:18:58PM +0100, Daniel Stone wrote: > Now that the interface has been proven by a port of Weston (using all > atomic features including TEST_ONLY), remove the module parameter > guarding the atomic API from being exposed, and let it run free in the > wild. > > Signed-off-

Linux 4.1 WARNING in drm_ioctl.c

On Tue, Jun 23, 2015 at 12:46:09PM +0200, Fabio Coatti wrote: > In data martedì 23 giugno 2015 11:48:47, Daniel Vetter ha scritto: > > On Tue, Jun 23, 2015 at 08:27:13AM +0100, Daniel Stone wrote: > > > Hi, > > > > > > On 23 June 2015 at 07:39, Daniel Vetter wrote: > > > > Which drm driver are y

[PATCH] drm/i915: enable BIOS hang workaround for Lenovo T60 too

On ti, 2015-06-23 at 13:42 +0300, Mikko Rapeli wrote: > Hi Imre, > > On Mon, Jun 22, 2015 at 04:43:50PM +0300, Imre Deak wrote: > > > > To summarize, since we extended the range of platforms to apply the > > workaround in > > commit ab3be73fa7b43f4c3648ce29b5fd649ea54d3adb > > Author: Imre Deak >

[PATCH v2 6/6] platform: recognize GM20B

Allow the platform driver to recognize GM20B. Signed-off-by: Alexandre Courbot --- drm/nouveau/nouveau_platform.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drm/nouveau/nouveau_platform.c b/drm/nouveau/nouveau_platform.c index dcfbbfaf1739..7a39d449fefa 100644 --- a/drm/nouveau/nouveau_

[PATCH v2 5/6] device: recognize GM20B

Recognize GM20B and assign the right engines and subdevs. Signed-off-by: Alexandre Courbot --- drm/nouveau/nvkm/engine/device/gm100.c | 20 1 file changed, 20 insertions(+) diff --git a/drm/nouveau/nvkm/engine/device/gm100.c b/drm/nouveau/nvkm/engine/device/gm100.c index 7

[PATCH v2 4/6] gr: add GM20B support

Add support for GM20B's graphics engine, based on GK20A. Note that this code alone will not allow the engine to initialize on released devices which require PMU-assisted secure boot. Signed-off-by: Alexandre Courbot --- drm/nouveau/include/nvkm/engine/gr.h | 1 + drm/nouveau/nvkm/engine/gr/Kb

[PATCH v2 3/6] fifo: add GM20B fifo

GM20B has a 512-channels FIFO similar to GK104. Signed-off-by: Alexandre Courbot --- drm/nouveau/include/nvkm/engine/fifo.h | 1 + drm/nouveau/nvkm/engine/fifo/Kbuild| 1 + drm/nouveau/nvkm/engine/fifo/gk104.h | 4 drm/nouveau/nvkm/engine/fifo/gm204.c | 2 +- drm/nouveau/nvkm/en

[PATCH v2 2/6] gr/gk20a: use same initialization sequence as nvgpu

GK20A's initialization was based on GK104, but differences exist in the way the initial context is built and the initialization process itself. This patch follows the same initialization sequence as nvgpu performs to avoid bad surprises. Since the register bundles initialization also differ consid

[PATCH v2 1/6] gr: use NVIDIA-provided external firmwares

NVIDIA will officially start providing GR firmwares through linux-firmware for GPUs that require it. Change the GR firmware lookup function to use these files. Signed-off-by: Alexandre Courbot --- drm/nouveau/nvkm/engine/gr/gf100.c | 31 +++ 1 file changed, 19 inserti

[PATCH v2 0/6] Improve GK20A support, introduce GM20B, firmware paths

Second version of this patchset. Not many changes since first version - I hope this means the changes are not too controversial. Changes since v1: - Removed lookup for previous FW files in "nouveau/" - Went back to using request_firmware() since we only try to load one file Original cover letter

[PATCH] of: fix a build error to f_graph_get_endpoint_by_regs function

This patch fixes the below build error reported by Stephen, https://lkml.org/lkml/2015/6/22/665 To fix the error, this patch declares of_graph_get_endpoint_by_regs function with "static inline". Signed-off-by: Inki Dae --- include/linux/of_graph.h |2 +- 1 file changed, 1 insertion(

[PATCH] drm: rcar-du: Remove obsolete rcar-du-r8a779x platform_device_id entries

Since commit a483dcbfa21f919c ("ARM: shmobile: lager: Remove legacy board support"), R-Car Gen2 SoCs are only supported in generic DT-only ARM multi-platform builds. The driver doesn't need to match platform devices by name anymore, hence remove the corresponding platform_device_id entry. Signed-

[patch -next] drm/radeon: missing break statement

There was a merge problem in linux-next 4598d330d29e ('Merge remote-tracking branch 'drm/drm-next''). We need to add a break statement. Signed-off-by: Dan Carpenter diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c index b4b457d..4a119c2 100644 --- a/driver

drm: imx: multi-display support questions

On Tue, Jun 23, 2015 at 2:49 PM, Fabio Estevam wrote: > Hi Gary, > > On Wed, May 27, 2015 at 10:31 AM, Gary Bisson > wrote: > >> Ok, thanks, I'll check and see what I need to get all the displays to >> work together. > > With this patch: > http://lists.infradead.org/pipermail/linux-arm-kernel/201

drm: imx: multi-display support questions

Hi Gary, On Wed, May 27, 2015 at 10:31 AM, Gary Bisson wrote: > Ok, thanks, I'll check and see what I need to get all the displays to > work together. With this patch: http://lists.infradead.org/pipermail/linux-arm-kernel/2015-June/352189.html I am able to get HDMI and LVDS working on a mx6q-s

[PATCH] drm: Always enable atomic API

Now that the interface has been proven by a port of Weston (using all atomic features including TEST_ONLY), remove the module parameter guarding the atomic API from being exposed, and let it run free in the wild. Signed-off-by: Daniel Stone Cc: Daniel Vetter --- drivers/gpu/drm/drm_drv.c | 2

[patch -next] drm/radeon: missing break statement

On 23.06.2015 13:51, Dan Carpenter wrote: > There was a merge problem in linux-next 4598d330d29e ('Merge > remote-tracking branch 'drm/drm-next''). We need to add a break > statement. > > Signed-off-by: Dan Carpenter Good catch, fortunately only an issue in drm-next. Reviewed-by: Christian Kön

mx6 hdmi resolution behaviour

On Tue, Jun 23, 2015 at 1:44 PM, Russell King - ARM Linux wrote: > If you have no connected connectors, then you get 1024x768: > > imx-drm display-subsystem: No connectors reported connected with modes > [drm] Cannot find any crtc or sizes - going 1024x768 > > as that's what DRM defaults to when

[PATCH] drm/i915: enable BIOS hang workaround for Lenovo T60 too

Hi Imre, On Mon, Jun 22, 2015 at 04:43:50PM +0300, Imre Deak wrote: > > To summarize, since we extended the range of platforms to apply the > workaround in > commit ab3be73fa7b43f4c3648ce29b5fd649ea54d3adb > Author: Imre Deak > Date: Mon Mar 2 13:04:41 2015 +0200 > > drm/i915: gen4: work a

mx6 hdmi resolution behaviour

Hi, On a imx6q-cubox-i running 4.1 kernel I am getting 1920x1080 HDMI resolution if I boot the board with the HDMI cable connected. If I boot it without the HDMI cable and then connect it afterwards, the resolution goes to only 1024 x 768 and the following IPU message is seen: [ 16.310548] imx

[PATCH libdrm] intel: Add EXEC_OBJECT_SUPPORTS_48BADDRESS flag.

Gen8+ supports 48-bit virtual addresses, but some objects must always be allocated inside the 32-bit address range. In specific, any resource used with flat/heapless (0x-0xf000) General State Heap (GSH) or Intruction State Heap (ISH) must be in a 32-bit range, because the General State

[PATCH 3/3] drm: Reject DRI1 hw lock ioctl functions for kms drivers

On Tue, 2015-06-23 at 11:37 +0200, Daniel Vetter wrote: > I've done some extensive history digging across libdrm, mesa and > xf86-video-{intel,nouveau,ati}. The only potential user of this with > kms drivers I could find was ttmtest, which once used drmGetLock > still. But that mistake was quickly

[PATCH 2/3] drm: Convert drm_legacy_ctxbitmap_init to void return type

On Tue, 2015-06-23 at 11:37 +0200, Daniel Vetter wrote: > It can't fail really. > > Also remove the redundant kms check Peter added. > > Cc: Peter Antoine > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_context.c | 5 ++--- > drivers/gpu/drm/drm_drv.c | 10 +- > drivers

[PATCH 1/3] drm: Turn off Legacy Context Functions

On Tue, 2015-06-23 at 11:37 +0200, Daniel Vetter wrote: > From: Peter Antoine > > The context functions are not used by the i915 driver and should not > be used by modeset drivers. These driver functions contain several bugs > and security holes. This change makes these functions optional can be

[PATCH v6 15/15] ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi'

On 23.06.2015 11:28, Inki Dae wrote: > On 2015년 06월 23일 11:10, Krzysztof Kozlowski wrote: >> 2015-06-22 21:35 GMT+09:00 Krzysztof Kozlowski : >>> 2015-06-22 20:42 GMT+09:00 Inki Dae : + Krzysztof On 2015년 06월 22일 18:10, Inki Dae wrote: > On 2015년 06월 12일 21:59,

Linux 4.1 WARNING in drm_ioctl.c

In data martedì 23 giugno 2015 11:48:47, Daniel Vetter ha scritto: > On Tue, Jun 23, 2015 at 08:27:13AM +0100, Daniel Stone wrote: > > Hi, > > > > On 23 June 2015 at 07:39, Daniel Vetter wrote: > > > Which drm driver are you using? I didn't spot anything in your module > > > list > > > but might

Linux 4.1 WARNING in drm_ioctl.c

On Tue, Jun 23, 2015 at 08:27:13AM +0100, Daniel Stone wrote: > Hi, > > On 23 June 2015 at 07:39, Daniel Vetter wrote: > > Which drm driver are you using? I didn't spot anything in your module list > > but might have missed it. Booting with drm.debug=0xe and grabbing dmesg > > will tell us for su

[PATCH 3/3] drm: Reject DRI1 hw lock ioctl functions for kms drivers

I've done some extensive history digging across libdrm, mesa and xf86-video-{intel,nouveau,ati}. The only potential user of this with kms drivers I could find was ttmtest, which once used drmGetLock still. But that mistake was quickly fixed up. Even the intel xvmc library (which otherwise was reall

[PATCH 2/3] drm: Convert drm_legacy_ctxbitmap_init to void return type

It can't fail really. Also remove the redundant kms check Peter added. Cc: Peter Antoine Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_context.c | 5 ++--- drivers/gpu/drm/drm_drv.c | 10 +- drivers/gpu/drm/drm_legacy.h | 2 +- 3 files changed, 4 insertions(+), 13 deletio

[PATCH 1/3] drm: Turn off Legacy Context Functions

From: Peter Antoine The context functions are not used by the i915 driver and should not be used by modeset drivers. These driver functions contain several bugs and security holes. This change makes these functions optional can be turned on by a setting, they are turned off by default for modeset

[PATCH v6 06/15] of: add helper for getting endpoint node of specific identifiers

On 2015년 06월 23일 09:19, Dave Airlie wrote: > On 12 June 2015 at 22:59, Hyungwon Hwang wrote: >> When there are multiple ports or multiple endpoints in a port, they have to >> be >> distinguished by the value of reg property. It is common. The drivers can get >> the specific endpoint in the

[PATCH v6 15/15] ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi'

On 2015년 06월 23일 11:10, Krzysztof Kozlowski wrote: > 2015-06-22 21:35 GMT+09:00 Krzysztof Kozlowski : >> 2015-06-22 20:42 GMT+09:00 Inki Dae : >>> + Krzysztof >>> >>> On 2015년 06월 22일 18:10, Inki Dae wrote: On 2015년 06월 12일 21:59, Hyungwon Hwang wrote: > The clock which w

[PATCH 1/5] drm/omap: return error if dma_alloc_writecombine fails

dd(&omap_obj->mm_list, &priv->obj_list); + spin_unlock(&priv->list_lock); + omap_obj->flags = flags; if (flags & OMAP_BO_TILED) { -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150623/bda69cea/attachment.sig>

[PATCH v6 15/15] ARM: dts: rename the clock of MIPI DSI 'pll_clk' to 'sclk_mipi'

2015-06-22 21:35 GMT+09:00 Krzysztof Kozlowski : > 2015-06-22 20:42 GMT+09:00 Inki Dae : >> + Krzysztof >> >> On 2015년 06월 22일 18:10, Inki Dae wrote: >>> On 2015년 06월 12일 21:59, Hyungwon Hwang wrote: The clock which was named as 'pll_clk' is actually not the clock source of PL

[PATCH v5 4/6] drm: bridge/dw_hdmi-i2s-audio: add audio driver

Russell, 在 2015/6/22 18:10, Russell King - ARM Linux 写道: > On Mon, Jun 22, 2015 at 12:06:04PM +0200, Paul Bolle wrote: >> But I think there's no platform_device with a "dw-hdmi-i2s-audio" name. >> So I wonder whether this MODULE_ALIAS() is actually needed. What breaks >> if you leave it out?

[PATCH v5 4/6] drm: bridge/dw_hdmi-i2s-audio: add audio driver

Paul, 在 2015/6/22 18:06, Paul Bolle 写道: > Something I didn't notice in v4, sorry. > > On Sat, 2015-06-20 at 00:28 +0800, Yakir Yang wrote: >> --- /dev/null >> +++ b/drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c >> +#define DRIVER_NAME "dw-hdmi-i2s-audio" >> +MODULE_ALIAS(PLATFORM_MODULE_PREFIX

[PATCH 2/5] drm/omap: check that plane is inside crtc

whether we couldn't clip the plane in software instead of failing. > This patch is fine though (except for the problem above), clipping can be > implemented in a separate patch. I had the same thought, but I didn't want to go that way yet. I have a feeling that it could have corner cases that need to be taken care of, and I just wanted to fix the current behavior. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150623/06361ab4/attachment.sig>

[PATCH 1/3] drm/msm: dsi host: add missing of_node_put()

On 06/22/2015 09:30 PM, Srinivas Kandagatla wrote: > > > On 22/06/15 15:54, Archit Taneja wrote: >> Decrement device node refcount if of_get_child_by_name is successfully >> called. >> >> Signed-off-by: Archit Taneja >> --- >> drivers/gpu/drm/msm/dsi/dsi_host.c | 2 ++ >> 1 file changed, 2 ins

[Intel-gfx] [PATCH 2/5] drm/i915/irq: abstract irq storm hotplug disabling

On 22 June 2015 at 23:02, Daniel Vetter wrote: > On Thu, Jun 18, 2015 at 01:06:14PM +0300, Jani Nikula wrote: >> Continue abstracting hotplug storm related functions to clarify the >> code. This time, abstract hotplug irq storm related hotplug >> disabling. While at it, clean up the loop iterating

[PATCH v6 06/15] of: add helper for getting endpoint node of specific identifiers

On 12 June 2015 at 22:59, Hyungwon Hwang wrote: > When there are multiple ports or multiple endpoints in a port, they have to be > distinguished by the value of reg property. It is common. The drivers can get > the specific endpoint in the specific port via this function. Now the drivers > have to

Linux 4.1 WARNING in drm_ioctl.c

> Which drm driver are you using? I didn't spot anything in your module list > but might have missed it. Booting with drm.debug=0xe and grabbing dmesg > will tell us for sure. > -Daniel Attached the drm.debug output, grepped for "drm". Let me know if I stripped something useful. Thanks, -- Fabio -- next part -- A non-text attachment was scrubbed... Name: drm.debug.gz Type: application/gzip Size: 18040 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150623/12d04abd/attachment-0001.bin>

[PATCH Resend] of: fix a build error to f_graph_get_endpoint_by_regs function

On Tue, Jun 23, 2015 at 2:06 AM, Inki Dae wrote: > This patch fixes the below build error reported by Stephen, > > Stephen reported: > After merging the drm-exynos tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > drivers/media/i2c/adv7604.o: In funct

Linux 4.1 WARNING in drm_ioctl.c

On Mon, Jun 22, 2015 at 04:04:20PM +0200, Fabio Coatti wrote: > Hi All, > > just compiled 4.1 and just got this warning, twice, in my dmesg: > > > [lun giu 22 11:43:18 2015] [ cut here ] > [lun giu 22 11:43:18 2015] WARNING: CPU: 1 PID: 2184 at > drivers/gpu/drm/drm_ioct

[Intel-gfx] [PATCH 2/5] drm/i915/irq: abstract irq storm hotplug disabling

On Tue, Jun 23, 2015 at 10:29:27AM +1000, Dave Airlie wrote: > On 22 June 2015 at 23:02, Daniel Vetter wrote: > > On Thu, Jun 18, 2015 at 01:06:14PM +0300, Jani Nikula wrote: > >> Continue abstracting hotplug storm related functions to clarify the > >> code. This time, abstract hotplug irq storm r

Linux 4.1 WARNING in drm_ioctl.c

Hi, On 23 June 2015 at 07:39, Daniel Vetter wrote: > Which drm driver are you using? I didn't spot anything in your module list > but might have missed it. Booting with drm.debug=0xe and grabbing dmesg > will tell us for sure. That'd be vgem. Cheers, Daniel

[Intel-gfx] [v2 4/7] mfd: intel_soc_pmic_core: ADD PWM lookup table for CRC PMIC based PWM

On Mon, 22 Jun 2015, Daniel Vetter wrote: > On Mon, Jun 22, 2015 at 04:33:22PM +0530, Varka Bhadram wrote: > > Hi Shobhit Kumar, > > > > On 06/22/2015 04:24 PM, Shobhit Kumar wrote: > > > > >On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup > > >entry for the same to be use

[PATCH v5 1/3] drm/layerscape: Add Freescale DCU DRM driver

Hi all, Anybody have any comments for this series of patches? Any comments are welcomed. They had been send out for more than two monthes. Thanks. BR. Jianwei > -Original Message- > From: Jianwei Wang [mailto:jianwei.wang at freescale.com] > Sent: Friday, April 17, 2015 2:36 PM > To: ai

[GIT PULL] exynos-drm-next

Hi Dave, With this pull request, Exynos drm also supports atomic feature. However, this doesn't guarantee atomic operation yet so we will more enhance it later. Besides, it includes new drivers, MIC and DECON for Exynos5433 SoC, and iommu support and consolidation to driver initiali

[Bug 91045] problems with 10.6.x and glamor

ri-devel/attachments/20150623/777b50a4/attachment.html>