- 08 May, 2016 24 commits
-
-
Archit Taneja authored
Move the drm_connector registration from the encoder(HDMI/DSI etc) drivers to the msm platform driver. This will simplify the task of ensuring that the connectors are registered only after the drm_device itself is registered. The connectors' destroy ops are made to use kzalloc instead of devm_kzalloc to ensure that that the connectors can be successfully unregistered when the msm driver module is removed. The memory for the connectors is unallocated when drm_mode_config_cleanup() is called during either during an error or during driver remove. Signed-off-by:
Archit Taneja <architt@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@gmail.com>
-
Archit Taneja authored
Calling the legacy gpio_free on an invalid GPIO (a GPIO numbered -1) results in kernel warnings. This causes a lot of backtraces when we try to unload the drm/msm module. Call gpio_free only on valid GPIOs. Signed-off-by:
-
Rob Clark authored
Track the pid per submit, so we can print the name of the task which submitted the batch that caused the gpu to hang. Signed-off-by: -
Rob Clark authored
Signed-off-by: -
Rob Clark authored
Signed-off-by: -
Rob Clark authored
At this point, there is nothing left to fail. And submit already has a fence assigned and is added to the submit_list. Any problems from here on out are asynchronous (ie. hangcheck/recovery). Signed-off-by: -
Archit Taneja authored
The MDP4 driver tries to request and set voltages for regulators required by the DSI PLLs. Firstly, the MDP4 driver shouldn't manage the DSI regulators, this should be handled in the DSI driver. Secondly, it shouldn't try to set a fixed voltage for regulators. Voltage constraints should be specified on the regulator via DT and managed by the regulator core. Remove all the DSI PLL regulator related code from the MDP4 driver. It's managed in the DSI driver for MSM8960/APQ8064 already. Signed-off-by:
-
Archit Taneja authored
The eDP driver tries to set a fixed voltage for one of its regulators(vdda) before enabling it. This shouldn't be done by the driver, the voltage constraints should be specified on the regulator via DT and managed by the regulator core. A driver should call regulator_set_voltage only if it needs to change the voltage during runtime. Drop the regulator_set_voltage call. Mention in a comment the voltage that the regulator expects. Signed-off-by:
-
Archit Taneja authored
The voltage changing code in this driver is broken and should be removed. The driver sets a single, exact voltage on probe. Unless there is a very good reason for this (which should be documented in comments) constraints like this need to be set via the machine constraints, voltage setting in a driver is expected to be used in cases where the voltage varies at runtime. In addition client drivers should almost never be calling regulator_can_set_voltage(), if the device needs to set a voltage it needs to set the voltage and the regulator core will handle the case where the regulator is fixed voltage. If the driver simply skips setting the voltage if it doesn't have permission then it should just not bother in the first place. Originally authored by Mark Brown <broonie@kernel.org> Remove the min/max voltage data entries per SoC managed by the driver. These aren't needed as we don't try to set voltages any more. Mention in comments the voltages that each regulator expects. Signed-off-by:
-
Vaishali Thakkar authored
Here, a location is reset to NULL before being passed to PTR_ERR. So, PTR_ERR should be called before its argument is reassigned to NULL. Further to simplify things use PTR_ERR_OR_ZERO instead of PTR_ERR and IS_ERR. Problem found using Coccinelle. Signed-off-by:
Vaishali Thakkar <vaishali.thakkar@oracle.com> Reviewed-by:
Eric Engestrom <eric.engestrom@imgtec.com> [fixed fmt string warning (s/%ld/%d/)] Signed-off-by:
-
Rob Herring authored
Android needs XBGR8888 format. Add all the missing 32-bpp formats without alpha for completeness. Cc: Archit Taneja <architt@codeaurora.org> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Arnd Bergmann authored
A recent cleanup removed the only user of the 'kms' variable in msm_preclose(), causing a harmless compiler warning: drivers/gpu/drm/msm/msm_drv.c: In function 'msm_preclose': drivers/gpu/drm/msm/msm_drv.c:468:18: error: unused variable 'kms' [-Werror=unused-variable] This removes the variable as well. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: 4016260b ("drm/msm: fix bug after preclose removal") Signed-off-by:
-
Rob Clark authored
It is no longer true that we discard all in-flight submits on recover (these days we only discard the first one that hung). After the first re-submitted batch completes it would overwrite the fence with a correct value, but there would be a window of time which showed all re-submitted batches as already complete. Signed-off-by: -
Rob Clark authored
Signed-off-by: -
Rob Clark authored
This was only used for atomic commit these days. So instead just give atomic it's own work-queue where we can do a block on each bo in turn. Simplifies things a whole bunch and makes the 'struct fence' conversion easier. Signed-off-by: -
Rob Clark authored
Better encapsulate the per-timeline stuff into fence-context. For now there is just a single fence-context, but eventually we'll also have one per-CRTC to enable fully explicit fencing. Signed-off-by: -
Rob Clark authored
Split up locking and pinning buffers in the submit path. This is needed because we'll want to insert fencing in between the two steps. This makes things end up looking more similar to etnaviv submit code (which was originally modelled on the msm code but has already added 'struct fence' support). Signed-off-by: -
Rob Clark authored
Since we already track the array of bo's in the submit object, just unconditionally take and drop ref's per submit (rather than only taking ref's if bo is not already active). This simplifies later patches. Signed-off-by: -
Rob Clark authored
Signed-off-by: -
Rob Clark authored
This was always the intention, but somehow it was never wired up properly. Signed-off-by: -
Rob Clark authored
Signed-off-by: -
Rob Clark authored
Signed-off-by: -
Rob Clark authored
In the atomic modesetting path, each driver simply wants to grab a ref to the exclusive fence from a reservation object to store in the incoming drm_plane_state, without doing the whole RCU dance. Since each driver will need to do this, lets make a helper. v2: rename to _rcu instead of _unlocked to be more consistent Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org>
-
Rob Clark authored
It is already optional at runtime. But this at least simplifies backports to kernels without QCOM_SCM. Signed-off-by:
-
- 05 May, 2016 6 commits
-
-
Dave Airlie authored
Don't just free the connector when we get the destroy callback. Drop a reference to it, and set it's mst_port to NULL so no more mst work is done on it. v2: core mst accepts NULLs fine. Cleanup EDID code properly. v3: drop the extra reference we were taking. Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
Take a reference when setting a crtc on a connecter, also take one when duplicating if a crtc is set, and drop one on destroy if a crtc is set. v2: take Daniel Stone's advice and simplify the ref/unref dances, also take care of NULL as connector to state reset. v3: remove need for connector NULL check. Reviewed-by:
Daniel Stone <daniels@collabora.com> Reviewed-by:
-
Dave Airlie authored
This just takes a reference on the connector when we set a mode in the non-atomic paths. v2: Follow Daniel Stone's suggestions on when to take/drop references. Reviewed-by:
-
Dave Airlie authored
This takes a reference count when fbdev adds the connector, and drops it when it removes the connector. It also drops the now unneeded code to find connectors and remove the from the modeset as they are reference counted. v2: drop references when removing all connectors at end. Reviewed-by:
-
Dave Airlie authored
This uses the previous changes to add reference counts to drm connector objects. v2: move fbdev changes to their own patch. add some kerneldoc Reviewed-by:
-
Dave Airlie authored
Reviewed-by:
-
- 04 May, 2016 10 commits
-
-
git://anongit.freedesktop.org/drm-intelDave Airlie authored
Ofc I promise just a few leftovers for drm-misc and somehow it's the biggest pull. But really mostly trivial stuff: - MAINTAINERS updates from Emil - rename async to nonblock in atomic_commit to avoid the confusion between nonblocking ioctl and async flip (= not vblank synced), from Maarten. Needs to be regened with newer drivers, but probably only after -rc1 to catch them all. - actually lockless gem_object_free, plus acked driver conversion patches. All the trickier prep stuff already is in drm-next. - Noralf's nice work for generic defio support in our fbdev emulation. Keeps the udl hack, and qxl is tested by Gerd. * tag 'topic/drm-misc-2016-05-04' of git://anongit.freedesktop.org/drm-intel: (47 commits) drm: Fixup locking WARN_ON mistake around gem_object_free_unlocked drm/etnaviv: Use lockless gem BO free callback drm/imx: Use lockless gem BO free callback drm/radeon: Use lockless gem BO free callback drm/amdgpu: Use lockless gem BO free callback drm/gem: support BO freeing without dev->struct_mutex MAINTAINERS: Add myself for the new VC4 (RPi GPU) graphics driver. MAINTAINERS: Add a bunch of legacy (UMS) DRM drivers MAINTAINERS: Add a few DRM drivers by Dave Airlie MAINTAINERS: List the correct git repo for the Renesas DRM drivers MAINTAINERS: Update the files list for the Renesas DRM drivers MAINTAINERS: Update the files list for the Armada DRM driver MAINTAINERS: Update the files list for the Rockchip DRM driver MAINTAINERS: Update the files list for the Exynos DRM driver MAINTAINERS: Add maintainer entry for the VMWGFX DRM driver MAINTAINERS: Add maintainer entry for the MSM DRM driver MAINTAINERS: Add maintainer entry for the Nouveau DRM driver MAINTAINERS: Update the files list for the Etnaviv DRM driver MAINTAINERS: Remove unneded wildcard for the i915 DRM driver drm/atomic: Add WARN_ON when state->acquire_ctx is not set. ...
-
Daniel Vetter authored
Embarrassingly while fixing up the old paths for i915 I managed to misplace a locking check for the new _unlocked paths. That's what I get for not retesting on radeon. Fixes: 9f0ba539 ("drm/gem: support BO freeing without dev->struct_mutex") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Tested-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Daniel Vetter authored
No dev->struct_mutex anywhere to be seen. Cc: Christian Gmeiner <christian.gmeiner@gmail.com> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Cc: Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Acked-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Daniel Vetter authored
No dev->struct_mutex anywhere to be seen. Cc: Sascha Hauer <s.hauer@pengutronix.de> Cc: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
-
Daniel Vetter authored
No dev->struct_mutex anywhere to be seen. Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Daniel Vetter authored
No dev->struct_mutex anywhere to be seen. Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Daniel Vetter authored
Finally all the core gem and a lot of drivers are entirely free of dev->struct_mutex depencies, and we can start to have an entirely lockless unref path. To make sure that no one who touches the core code accidentally breaks existing drivers which still require dev->struct_mutex I've made the might_lock check unconditional. While at it de-inline the ref/unref functions, they've become a bit too big. v2: Make it not leak like a sieve. v3: Review from Lucas: - drop != NULL in pointer checks. - fixup copypasted kerneldoc to actually match the functions. v4: Add __drm_gem_object_unreference as a fastpath helper for drivers who abolished dev->struct_mutex, requested by Chris. v5: Fix silly mistake in drm_gem_object_unreference_unlocked caught by intel-gfx CI - I checked for gem_free_object instead of gem_free_object_unlocked ... Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Lucas Stach <l.stach@pengutronix.de> (v3) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v4) Reviewed-by:
-
Dave Airlie authored
drm-hisilicon-next for 4.7 Add new hisilicon kirin drm driver: - Add maintainer for hisilicon DRM driver - Add support for external bridge - Add designware dsi host driver - Add designware dsi encoder driver - Add cma fbdev and hotplug - Add vblank driver for ADE - Add plane driver for ADE - Add crtc driver for ADE - Add hisilicon kirin drm master driver - Add device tree binding for hi6220 display subsystem * tag 'drm-hisilicon-next-2016-04-29' of github.com:xin3liang/linux: MAINTAINERS: Add maintainer for hisilicon DRM driver drm/hisilicon: Add support for external bridge drm/hisilicon: Add designware dsi host driver drm/hisilicon: Add designware dsi encoder driver drm/hisilicon: Add cma fbdev and hotplug drm/hisilicon: Add vblank driver for ADE drm/hisilicon: Add plane driver for ADE drm/hisilicon: Add crtc driver for ADE drm/hisilicon: Add hisilicon kirin drm master driver drm/hisilicon: Add device tree binding for hi6220 display subsystem
-
git://people.freedesktop.org/~gabbayo/linuxDave Airlie authored
Here are a few amdkfd patches for 4.7, all of them fixes according to the Coccinelle tool. * tag 'drm-amdkfd-next-2016-05-04' of git://people.freedesktop.org/~gabbayo/linux: amdkfd: Trim unnescessary intermediate err var in kfd_chardev.c amdkfd: Trim off unnescessary semicolon from kfd_packet_manager.c amdkfd: Use the canonical form in branch predicates
-
Dave Airlie authored
Merge branch 'drm-rockchip-next-fixes-05-03' of https://github.com/markyzq/kernel-drm-rockchip into drm-next Here are some little fixes for rockchip drm, looks good for me, and seems there is no doubt on them, So I'd like you can land them. * 'drm-rockchip-next-fixes-05-03' of https://github.com/markyzq/kernel-drm-rockchip: drm/rockchip: vop: Initialize vskiplines to zero drm/rockchip: vop: fix iommu crash with async atomic drm/rockchip: support non-iommu buffer path drm/rockchip: get rid of rockchip_drm_crtc_mode_config drm/rockchip: inno_hdmi: fix an error code drm/rockchip: don't leak iommu mapping drm/rockchip: remove redundant statement
-
