[Bug 64600] r600g pyrit OpenCL issue on HD6850
https://bugs.freedesktop.org/show_bug.cgi?id=64600 --- Comment #17 from Tom Stellard --- Thanks for adding the tests. It would be great if you could send these as patches to pig...@lists.freedesktop.org, so we can add them to the test suite. This patch should fix the struct copy tests: http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131014/191163.html -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 27/27] drm/tegra: Add Tegra114 gr2d support
On 14.10.2013 21:14, Stephen Warren wrote:
> On 10/14/2013 08:00 AM, Thierry Reding wrote:
>> Yes, as long as the device tree files includes the most specific
>> value in the compatible this should still be possible. So we'd have
>> this:
>>
>> gr2d@5414 { compatible = "nvida,tegra114-gr2d",
>> "nvidia,tegra20-gr2d"; ... };
>>
>> and the driver will match on "nvidia,tegra20-gr2d" if the more
>> specific "nvidia,tegra114-gr2d" is not there. When the driver is
>> updated to support Tegra114 specific functionality, then a more
>> specific entry can be added to the compatible table to handle it.
>
> True, but the DT fragment above is also only accurate /if/ a driver
> that only knows about "nvidia,tegra20-gr2d" can operate 100% of the
> features in Tegra20 HW on Tegra114 HW forever.
I don't know of any hardware incompatibility. The only difference is
related to something not directly to 2D. We moved host1x away from the
power domain, so in Tegra114 we're able to power gate 2D and EPP. The
DVFS tables are also different.
I'd say say adding the compatible property "nvidia,tegra20-gr2d" for
Tegra114's 2D is accurate and we're able to use the match table to drive
any SW policy differences.
Terje
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60691] [radeon HD5450 ] UVD don't work after resume from hibernate
https://bugzilla.kernel.org/show_bug.cgi?id=60691 --- Comment #3 from Egor Y. Egorov --- Created attachment 111031 --> https://bugzilla.kernel.org/attachment.cgi?id=111031&action=edit dmesg from 3.12-rc5 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60691] [radeon HD5450 ] UVD don't work after resume from hibernate
https://bugzilla.kernel.org/show_bug.cgi?id=60691 --- Comment #2 from Egor Y. Egorov --- (In reply to Alex Deucher from comment #1) > Looks like a duplicate of: > https://bugs.freedesktop.org/show_bug.cgi?id=67187 This bug is closed now. But in my case bug not resolved. Reproduced on 3.11.5 and 3.12-rc5 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/23] drm/exynos: Split manager/display/subdrv
2013/10/15 Inki Dae :
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> index c417c90..ba63c72 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
>> @@ -26,24 +26,23 @@
>> * exynos specific encoder structure.
>> *
>> * @drm_encoder: encoder object.
>> - * @manager: specific encoder has its own manager to control a hardware
>> - * appropriately and we can access a hardware drawing on this manager.
>> + * @display: the display structure that maps to this encoder
>> */
>> struct exynos_drm_encoder {
>> struct drm_crtc *old_crtc;
>> struct drm_encoder drm_encoder;
>> - struct exynos_drm_manager *manager;
>> + struct exynos_drm_display *display;
>> };
>>
>> static void exynos_drm_encoder_dpms(struct drm_encoder *encoder, int mode)
>> {
>> - struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
>> - struct exynos_drm_display_ops *display_ops = manager->display_ops;
>> + struct exynos_drm_encoder *exynos_encoder =
>> to_exynos_encoder(encoder);
>> + struct exynos_drm_display *display = exynos_encoder->display;
>>
>> DRM_DEBUG_KMS("encoder dpms: %d\n", mode);
>>
>> - if (display_ops && display_ops->dpms)
>> - display_ops->dpms(manager->ctx, mode);
>> + if (display->ops->dpms)
>> + display->ops->dpms(display->ctx, mode);
>
> It's good to remove apply callback. However, it seems that this patch
> has a problem that dma channel of fimd isn't enabled after dpms goes
> from off to on. So can you implement win_enable callback of fimd, and
> add it to fimd_win_resume function? We should have implemented
> win_enable callback.
>
Plz, ignore the above comments, and see the below comments.
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> index 838c47d..f3dc808 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
>> @@ -105,7 +105,6 @@ struct fimd_win_data {
>> };
>>
>> struct fimd_context {
>> - struct exynos_drm_subdrvsubdrv;
>> struct device *dev;
>> struct drm_device *drm_dev;
>> int irq;
>> @@ -120,6 +119,7 @@ struct fimd_context {
>> u32 vidcon0;
>> u32 vidcon1;
>> boolsuspended;
>> + int pipe;
>> struct mutexlock;
>> wait_queue_head_t wait_vsync_queue;
>> atomic_twait_vsync_event;
>> @@ -169,12 +169,16 @@ static int fimd_check_mode(void *in_ctx, struct
>> drm_display_mode *mode)
>> }
>>
>> static struct exynos_drm_display_ops fimd_display_ops = {
>> - .type = EXYNOS_DISPLAY_TYPE_LCD,
>> .is_connected = fimd_display_is_connected,
>> .get_panel = fimd_get_panel,
>> .check_mode = fimd_check_mode,
>> };
>>
>> +static struct exynos_drm_display fimd_display = {
>> + .type = EXYNOS_DISPLAY_TYPE_LCD,
>> + .ops = &fimd_display_ops,
>> +};
>> +
>> static void fimd_win_mode_set(void *in_ctx, struct exynos_drm_overlay
>> *overlay)
>> {
>> struct fimd_context *ctx = in_ctx;
>> @@ -481,15 +485,46 @@ static void fimd_win_disable(void *in_ctx, int zpos)
>> win_data->enabled = false;
>> }
>>
>> -static int fimd_mgr_initialize(void *in_ctx, struct drm_device *drm_dev)
>> +static int fimd_mgr_initialize(void *in_ctx, struct drm_device *drm_dev,
>> + int pipe)
>> {
>> struct fimd_context *ctx = in_ctx;
>>
>> ctx->drm_dev = drm_dev;
>> + ctx->pipe = pipe;
>> +
>> + /*
>> +* enable drm irq mode.
>> +* - with irq_enabled = 1, we can use the vblank feature.
>> +*
>> +* P.S. note that we wouldn't use drm irq handler but
>> +* just specific driver own one instead because
>> +* drm framework supports only one irq handler.
>> +*/
>> + ctx->drm_dev->irq_enabled = 1;
>> +
>> + /*
>> +* with vblank_disable_allowed = 1, vblank interrupt will be disabled
>> +* by drm timer once a current process gives up ownership of
>> +* vblank event.(after drm_vblank_put function is called)
>> +*/
>> + drm_dev->vblank_disable_allowed = 1;
>> +
>> + /* attach this sub driver to iommu mapping if supported. */
>> + if (is_drm_iommu_supported(ctx->drm_dev))
>> + drm_iommu_attach_device(ctx->drm_dev, ctx->dev);
>>
>> return 0;
>> }
>>
>> +static void fimd_mgr_remove(void *in_ctx)
>> +{
>> + struct fimd_context *ctx = in_ctx;
>> +
>> + if (is_drm_iommu_supported(ctx->drm_dev))
>>
[PATCH v2] drm/exynos: fimd: clean up pm suspend/resume
This patch removes unnecessary runtime pm related function calls
from fimd_suspend and fimd_resume functions.
Changelog v2:
- use UNIVERSAL_DEV_PM_OPS macro instead.
Signed-off-by: Inki Dae
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 59 ++
1 file changed, 12 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
index 5d5b97d..35f2c97 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c
@@ -1003,66 +1003,31 @@ static int fimd_suspend(struct device *dev)
{
struct fimd_context *ctx = get_fimd_context(dev);
- /*
-* do not use pm_runtime_suspend(). if pm_runtime_suspend() is
-* called here, an error would be returned by that interface
-* because the usage_count of pm runtime is more than 1.
-*/
- if (!pm_runtime_suspended(dev))
- return fimd_activate(ctx, false);
-
- return 0;
+ return fimd_activate(ctx, false);
}
static int fimd_resume(struct device *dev)
{
struct fimd_context *ctx = get_fimd_context(dev);
+ int ret;
+
+ ret = fimd_activate(ctx, true);
+ if (ret < 0)
+ return ret;
/*
-* if entered to sleep when lcd panel was on, the usage_count
-* of pm runtime would still be 1 so in this case, fimd driver
-* should be on directly not drawing on pm runtime interface.
+* in case of dpms on(standby), fimd_apply function will
+* be called by encoder's dpms callback to update fimd's
+* registers but in case of sleep wakeup, it's not.
+* so fimd_apply function should be called at here.
*/
- if (!pm_runtime_suspended(dev)) {
- int ret;
-
- ret = fimd_activate(ctx, true);
- if (ret < 0)
- return ret;
-
- /*
-* in case of dpms on(standby), fimd_apply function will
-* be called by encoder's dpms callback to update fimd's
-* registers but in case of sleep wakeup, it's not.
-* so fimd_apply function should be called at here.
-*/
- fimd_apply(dev);
- }
+ fimd_apply(dev);
return 0;
}
#endif
-#ifdef CONFIG_PM_RUNTIME
-static int fimd_runtime_suspend(struct device *dev)
-{
- struct fimd_context *ctx = get_fimd_context(dev);
-
- return fimd_activate(ctx, false);
-}
-
-static int fimd_runtime_resume(struct device *dev)
-{
- struct fimd_context *ctx = get_fimd_context(dev);
-
- return fimd_activate(ctx, true);
-}
-#endif
-
-static const struct dev_pm_ops fimd_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(fimd_suspend, fimd_resume)
- SET_RUNTIME_PM_OPS(fimd_runtime_suspend, fimd_runtime_resume, NULL)
-};
+UNIVERSAL_DEV_PM_OPS(fimd_pm_ops, fimd_suspend, fimd_resume, NULL);
struct platform_driver fimd_driver = {
.probe = fimd_probe,
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68391] [radeonsi] Crash unigine-sanctuary
https://bugs.freedesktop.org/show_bug.cgi?id=68391 --- Comment #12 from Vladimir Ysikov --- (In reply to comment #11) > It seems that the commit 6e51c2a941955fd2a34d62437fc149e633e79ec7 "radeonsi: > Allow Sinking pass to move preloaded const/res/sampl" by Vincent Lejeune has > fixed this problem with Unigine Sanctuary and Unigine Heaven 3.0 for me. I test latest mesa-git and no more crash. looks like this bug fixed. But unigine-sanctuary now have wrong rendering and many error in output. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61811] kms mode breaks when using radeon.agpmode=-1
https://bugzilla.kernel.org/show_bug.cgi?id=61811 --- Comment #23 from Bruno Wolff III --- I have a Fedora bug for that issue. I'm starting to work on bisecting some older kernel bugs and may bring it back to the kernel when I'm done. But I'm starting on a sound / network / probable locking bug from 3 years ago. It will probably take me a couple of weeks to get that one bisected. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #27 from bgunte...@gmail.com --- I will say, as I'm going through the menus, the artifacts are not as bad as they've been. so there is improvement! a lot of stuff that was completely unreadable i'm now able to read. close! i look forward to hearing from you, and testing whatever is needed. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63997] Artifacts using a HD7480D on a A4-5300 APU
https://bugs.freedesktop.org/show_bug.cgi?id=63997 --- Comment #26 from bgunte...@gmail.com --- i can concur... still getting the artifacts; for me in XBMC GUI. what else can we do to help? Logs? etc... -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70439] Mobility 4570: System freezes after ~5s of enabling audio via xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=70439 --- Comment #14 from Mohammad AlSaleh --- (In reply to comment #11) > Created attachment 87616 [details] [review] > possible fix > > Please try this patch and append radeon.audio=1 to the kernel command line > in grub. There appears to be a serious regression here. System hangs (black screens) if the HDMI monitor is connected before xinit. And hangs if the monitor is attached after xinit when enabled via xrandr. In the latter case, the hanged frame is displayed on the monitor, but before being resized to occupy the whole screen and with noise artifacts. Note: Everything works correctly with 3.11.5. 'radeon.audio=1' works with and without DPM. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70439] Mobility 4570: System freezes after ~5s of enabling audio via xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=70439 --- Comment #13 from Mohammad AlSaleh --- Created attachment 87633 --> https://bugs.freedesktop.org/attachment.cgi?id=87633&action=edit partial kernel log (3.12rc5 + patch 87616) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61811] kms mode breaks when using radeon.agpmode=-1
https://bugzilla.kernel.org/show_bug.cgi?id=61811 --- Comment #22 from Dieter Nützel --- (In reply to Bruno Wolff III from comment #0) > I need to use radeon.agpmode=-1 with my rv280 based graphics card due to a > long (2+ years) standing bug with the driver. Hello Bruno, isn't it then time to writing a bug report on bugs.freedesktop.org, that Christian König or Alex Deucher from AMD can look at it? Greetings, Dieter -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFCv2 02/13] drm: add atomic fxns
The 'atomic' mechanism allows for multiple properties to be updated, checked, and commited atomically. This will be the basis of atomic- modeset and nuclear-pageflip. The basic flow is: state = dev->atomic_begin(); for (... one or more ...) obj->set_property(obj, state, prop, value); if (dev->atomic_check(state)) dev->atomic_commit(state); dev->atomic_end(state); The split of check and commit steps is to allow for ioctls with a test-only flag (which would skip the commit step). --- drivers/gpu/drm/Makefile| 3 +- drivers/gpu/drm/ast/ast_drv.c | 6 ++ drivers/gpu/drm/ast/ast_drv.h | 1 + drivers/gpu/drm/cirrus/cirrus_drv.c | 6 ++ drivers/gpu/drm/cirrus/cirrus_drv.h | 1 + drivers/gpu/drm/drm_atomic_helper.c | 135 +++ drivers/gpu/drm/drm_crtc.c | 139 ++-- drivers/gpu/drm/exynos/exynos_drm_crtc.c| 4 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 7 ++ drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 +- drivers/gpu/drm/gma500/cdv_intel_crt.c | 4 +- drivers/gpu/drm/gma500/cdv_intel_dp.c | 4 +- drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 4 +- drivers/gpu/drm/gma500/cdv_intel_lvds.c | 4 +- drivers/gpu/drm/gma500/mdfld_dsi_output.c | 4 +- drivers/gpu/drm/gma500/psb_drv.c| 7 ++ drivers/gpu/drm/gma500/psb_drv.h| 1 + drivers/gpu/drm/gma500/psb_intel_drv.h | 4 +- drivers/gpu/drm/gma500/psb_intel_lvds.c | 4 +- drivers/gpu/drm/gma500/psb_intel_sdvo.c | 4 +- drivers/gpu/drm/i915/i915_drv.c | 8 ++ drivers/gpu/drm/i915/intel_crt.c| 4 +- drivers/gpu/drm/i915/intel_dp.c | 4 +- drivers/gpu/drm/i915/intel_drv.h| 1 + drivers/gpu/drm/i915/intel_hdmi.c | 4 +- drivers/gpu/drm/i915/intel_lvds.c | 4 +- drivers/gpu/drm/i915/intel_sdvo.c | 4 +- drivers/gpu/drm/i915/intel_tv.c | 5 +- drivers/gpu/drm/mgag200/mgag200_drv.c | 7 ++ drivers/gpu/drm/mgag200/mgag200_drv.h | 1 + drivers/gpu/drm/msm/mdp4/mdp4_crtc.c| 4 +- drivers/gpu/drm/msm/mdp4/mdp4_plane.c | 4 +- drivers/gpu/drm/msm/msm_drv.c | 6 ++ drivers/gpu/drm/msm/msm_drv.h | 1 + drivers/gpu/drm/nouveau/nouveau_connector.c | 3 +- drivers/gpu/drm/nouveau/nouveau_drm.c | 7 ++ drivers/gpu/drm/nouveau/nouveau_drm.h | 1 + drivers/gpu/drm/omapdrm/omap_crtc.c | 7 +- drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++ drivers/gpu/drm/omapdrm/omap_drv.h | 5 +- drivers/gpu/drm/omapdrm/omap_plane.c| 4 +- drivers/gpu/drm/qxl/qxl_display.c | 4 +- drivers/gpu/drm/qxl/qxl_drv.c | 9 ++ drivers/gpu/drm/radeon/radeon_connectors.c | 9 +- drivers/gpu/drm/radeon/radeon_drv.c | 9 ++ drivers/gpu/drm/rcar-du/rcar_du_drv.c | 7 ++ drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 +- drivers/gpu/drm/shmobile/shmob_drm_drv.c| 7 ++ drivers/gpu/drm/tilcdc/tilcdc_drv.c | 6 ++ drivers/gpu/drm/tilcdc/tilcdc_drv.h | 1 + drivers/gpu/drm/tilcdc/tilcdc_slave.c | 3 +- drivers/gpu/drm/udl/udl_connector.c | 6 +- drivers/gpu/drm/udl/udl_drv.c | 8 ++ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 7 ++ drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 + drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +- drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 4 +- drivers/gpu/host1x/drm/drm.c| 7 ++ drivers/gpu/host1x/drm/drm.h| 1 + drivers/staging/imx-drm/imx-drm-core.c | 8 ++ include/drm/drmP.h | 77 +++ include/drm/drm_atomic_helper.h | 100 include/drm/drm_crtc.h | 14 +-- 63 files changed, 634 insertions(+), 98 deletions(-) create mode 100644 drivers/gpu/drm/drm_atomic_helper.c create mode 100644 include/drm/drm_atomic_helper.h diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index f089adf..4e68e0d 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -13,7 +13,8 @@ drm-y :=drm_auth.o drm_buffer.o drm_bufs.o drm_cache.o \ drm_crtc.o drm_modes.o drm_edid.o \ drm_info.o drm_debugfs.o drm_encoder_slave.o \ drm_trace_points.o drm_global.o drm_prime.o \ - drm_rect.o drm_vma_manager.o drm_flip_work.o + drm_rect.o drm_vma_manager.o drm_flip_work.o \ + drm_atomic_helper.o drm-$(CONFIG_COMPAT) += drm_ioc32.o drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c index 32e270d..d78edaf 100644 --- a/drivers/gpu/drm/ast/ast_drv.c +++ b/drivers/gpu/drm/ast
[Bug 70439] Mobility 4570: System freezes after ~5s of enabling audio via xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=70439 --- Comment #12 from Mohammad AlSaleh --- (In reply to comment #10) > (In reply to comment #6) > > (In reply to comment #2) > > > Did you started audio before enabling it with "xrandr --output HDMI-0 > > > --set > > > audio auto" ? > > Had you started audio playback in the application before enabling it with > xrandr? If so, do you still get the hang if you enable audio with xrandr > first, and then start playback in the application? > > > > > radeon.audio=1 seems to have no effect! > > > > radeon.audio=1 is the default now. Upgraded to 3.12rc5. I get the hang in all cases. Even if I don't use an application at all. The hang sometimes happens so fast before xrandr exiting. And sometimes it takes ~90s. But I always get a hang at the end. I'll test with the patch now. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: stop the leaks in cik_ib_test
Ooops, the new problem is not so rare. It has now happened to me 3
times in an hour.
Marek
On Mon, Oct 14, 2013 at 9:13 PM, Marek Olšák wrote:
> I tested this and had over 1546 lockups followed by a successful GPU
> reset. Then the kernel probably crashed (judging by the fact ssh was
> dead). Still, it's pretty impressive.
>
> There is a new problem though. The X server sometimes gets stuck in
> GEM_WAIT and waits forever, even if there were no lockups before. It
> occurs very rarely though. I didn't see this issue without your
> patches.
>
> Marek
>
> On Mon, Oct 14, 2013 at 11:32 AM, Christian König
> wrote:
>> From: Christian König
>>
>> Stop leaking IB memory and scratch register space when the test fails.
>>
>> Signed-off-by: Christian König
>> ---
>> drivers/gpu/drm/radeon/cik.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
>> index b874ccd..8f393df 100644
>> --- a/drivers/gpu/drm/radeon/cik.c
>> +++ b/drivers/gpu/drm/radeon/cik.c
>> @@ -3182,6 +3182,7 @@ int cik_ib_test(struct radeon_device *rdev, struct
>> radeon_ring *ring)
>> r = radeon_ib_get(rdev, ring->idx, &ib, NULL, 256);
>> if (r) {
>> DRM_ERROR("radeon: failed to get ib (%d).\n", r);
>> + radeon_scratch_free(rdev, scratch);
>> return r;
>> }
>> ib.ptr[0] = PACKET3(PACKET3_SET_UCONFIG_REG, 1);
>> @@ -3198,6 +3199,8 @@ int cik_ib_test(struct radeon_device *rdev, struct
>> radeon_ring *ring)
>> r = radeon_fence_wait(ib.fence, false);
>> if (r) {
>> DRM_ERROR("radeon: fence wait failed (%d).\n", r);
>> + radeon_scratch_free(rdev, scratch);
>> + radeon_ib_free(rdev, &ib);
>> return r;
>> }
>> for (i = 0; i < rdev->usec_timeout; i++) {
>> --
>> 1.8.1.2
>>
>> ___
>> dri-devel mailing list
>> dri-devel@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: stop the leaks in cik_ib_test
I tested this and had over 1546 lockups followed by a successful GPU
reset. Then the kernel probably crashed (judging by the fact ssh was
dead). Still, it's pretty impressive.
There is a new problem though. The X server sometimes gets stuck in
GEM_WAIT and waits forever, even if there were no lockups before. It
occurs very rarely though. I didn't see this issue without your
patches.
Marek
On Mon, Oct 14, 2013 at 11:32 AM, Christian König
wrote:
> From: Christian König
>
> Stop leaking IB memory and scratch register space when the test fails.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/radeon/cik.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index b874ccd..8f393df 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -3182,6 +3182,7 @@ int cik_ib_test(struct radeon_device *rdev, struct
> radeon_ring *ring)
> r = radeon_ib_get(rdev, ring->idx, &ib, NULL, 256);
> if (r) {
> DRM_ERROR("radeon: failed to get ib (%d).\n", r);
> + radeon_scratch_free(rdev, scratch);
> return r;
> }
> ib.ptr[0] = PACKET3(PACKET3_SET_UCONFIG_REG, 1);
> @@ -3198,6 +3199,8 @@ int cik_ib_test(struct radeon_device *rdev, struct
> radeon_ring *ring)
> r = radeon_fence_wait(ib.fence, false);
> if (r) {
> DRM_ERROR("radeon: fence wait failed (%d).\n", r);
> + radeon_scratch_free(rdev, scratch);
> + radeon_ib_free(rdev, &ib);
> return r;
> }
> for (i = 0; i < rdev->usec_timeout; i++) {
> --
> 1.8.1.2
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 26/27] drm/tegra: Add DSI support
On 10/14/2013 07:55 AM, Thierry Reding wrote:
> On Fri, Oct 11, 2013 at 04:43:35PM -0600, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> This commit adds support for both DSI outputs found on Tegra. Only very
>>> minimal functionality is implemented, so advanced features like ganged
>>> mode won't work.
>>>
>>> Due to the lack of other test hardware, some sections of the driver are
>>> hardcoded to work with Dalmore.
>>
>>> diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
>>
>>> +static int tegra_dsi_show_regs(struct seq_file *s, void *data)
>>> +{
>>> + struct drm_info_node *node = s->private;
>>> + struct tegra_dsi *dsi = node->info_ent->data;
>>> +
>>> +#define DUMP_REG(name) \
>>> + seq_printf(s, "%-32s %#05x %08lx\n", #name, name, \
>>> + tegra_dsi_readl(dsi, name))
>>> +
>>> + DUMP_REG(DSI_INCR_SYNCPT);
>>
>> Does it make sense to use an MMIO regmap instead? That way, you get all
>> the debugfs files for free...
>
> As far as I know, regmap doesn't give you the symbolic names for the
> registers. I find that a rather useful feature because it allows to
> easily compare the registers to the ones in our downstream kernels.
True. However, we should really be writing user-space scripts to encode
that information. Such a script could be useful e.g. if reading the
information directly from /dev/mem or JTAG too, and bloating the kernel
with debug strings doesn't seem like a great idea.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 27/27] drm/tegra: Add Tegra114 gr2d support
On 10/14/2013 08:00 AM, Thierry Reding wrote:
> On Mon, Oct 14, 2013 at 08:58:34AM +0300, Terje Bergström wrote:
>> On 12.10.2013 01:43, Stephen Warren wrote:
>>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
The gr2d hardware in Tegra114 is compatible with that of
Tegra20 and Tegra30. No functionaly changes are required.
>>> Similarly here, if the HW is 100% backwards-compatible, there's
>>> no need to add compatible values to the driver.
>>
>> We've used this mechanism for attaching a per-hw-version data
>> structure in match table to accomodate differences in how the
>> hardware is power gated, reset, booted, some per-soc performance
>> related changes etc. It's also used in staging features for new
>> chips, such as disabling power features when they're not
>> working/verified yet.
>>
>> Upstream driver is not yet in a state where that is relevant.
>>
>> With this, would we still be able to do that with match table? It
>> sounds like we could, because we can still (even with multiple
>> compatible properties) add separate entries in match table and I
>> guess the compatible properties matched in order.
>
> Yes, as long as the device tree files includes the most specific
> value in the compatible this should still be possible. So we'd have
> this:
>
> gr2d@5414 { compatible = "nvida,tegra114-gr2d",
> "nvidia,tegra20-gr2d"; ... };
>
> and the driver will match on "nvidia,tegra20-gr2d" if the more
> specific "nvidia,tegra114-gr2d" is not there. When the driver is
> updated to support Tegra114 specific functionality, then a more
> specific entry can be added to the compatible table to handle it.
True, but the DT fragment above is also only accurate /if/ a driver
that only knows about "nvidia,tegra20-gr2d" can operate 100% of the
features in Tegra20 HW on Tegra114 HW forever.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 27/27] drm/tegra: Add Tegra114 gr2d support
On 10/13/2013 11:58 PM, Terje Bergström wrote: > On 12.10.2013 01:43, Stephen Warren wrote: >> On 10/07/2013 02:34 AM, Thierry Reding wrote: >>> The gr2d hardware in Tegra114 is compatible with that of Tegra20 and >>> Tegra30. No functionaly changes are required. >> >> Similarly here, if the HW is 100% backwards-compatible, there's no need >> to add compatible values to the driver. > > We've used this mechanism for attaching a per-hw-version data structure > in match table to accomodate differences in how the hardware is power > gated, reset, booted, some per-soc performance related changes etc. If there are differences in those aspects of the HW, such that a driver written only to the full specification of e.g. Tegra30 would not work on Tegra114, then the HW is not actually compatible, and hence we do need multiple compatible values in DT, and entries in the of_match table. It sounds like the statement in the commit description: >>> The gr2d hardware in Tegra114 is compatible with that of Tegra20 and >>> Tegra30. No functionaly changes are required. Might not be absolutely accurate in terms of HW, but only in terms of the features that the driver uses so far. It'd be good to explicitly qualify this in the commit description. ... > Upstream driver is not yet in a state where that is relevant. The compatible values should be picked based on the full feature-set of the HW, not based on the subset of features supported by a particular driver. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 17/27] drm/tegra: Add Tegra114 HDMI support
On 10/12/2013 05:41 AM, Thierry Reding wrote:
> On Fri, Oct 11, 2013 at 04:19:19PM -0600, Stephen Warren wrote:
>> On 10/07/2013 02:34 AM, Thierry Reding wrote:
>>> From: Mikko Perttunen
>>>
>>> Tegra114 TMDS configuration requires a new peak_current field
>>> and the driver current override bit has changed position.
>>
>>> diff --git a/drivers/gpu/drm/tegra/hdmi.c
>>> b/drivers/gpu/drm/tegra/hdmi.c
>>
>>> static const struct tmds_config tegra2_tmds_config[] = { @@
>>> -223,6 +224,85 @@ static const struct tmds_config
>>> tegra3_tmds_config[] = {
>>
>> Not related to this patch, but those should have been named
>> tegra20_tmds_config[] and tegra30_tmds_config[].
>>
>>> static void tegra_hdmi_setup_tmds(struct tegra_hdmi *hdmi,
>>
>>> - value = tmds->drive_current | DRIVE_CURRENT_FUSE_OVERRIDE; -
>>> tegra_hdmi_writel(hdmi, value,
>>> HDMI_NV_PDISP_SOR_LANE_DRIVE_CURRENT); +if
>>> (of_device_is_compatible(np, "nvidia,tegra114-hdmi")) {
>>
>> Let's not check this at run-time. Instead, host1x_drm_subdevs[]'s
>> .data field should be used to contain either flags or a pointer
>> to a configuration structure, either of which can be directly
>> consulted to determine the properties of the HW in a
>> feature-oriented/semantic way.
>>
>> drivers/gpio/gpio-tegra.c's
>> tegra20_gpio_config/tegra30_gpio_config/tegra_gpio_of_match
>> provide a good example of this.
>>
>> This means that if Tegra124 is identical to Tegra114, yet a
>> hypothetical Tegra999 is different, you don't have to keep
>> adjusting these if conditions throughout the code; they can
>> simply refer to the same feature bit forever.
>
> Okay, I'll see what I can come up with. It's unfortunately not as
> simple as the GPIO driver's parameterization, and who knows what
> other differences will be introduced in some later versions of this
> block.
>
> What I mean is that at some point it becomes questionable whether
> it makes sense to parameterize at all if you have to encode the
> register offset and bit position within that register for a large
> number of bits.
Well, I wasn't advocating that we shouldn't have an if statement at
all. Simply that the if statement shouldn't be doing string compares
of specific HW. Either of the following would be fine:
if (hdmi->soc_data->some_feature_flag)
// just represents some code; doesn't have to be a function call
do_something();
else;
do_something_else();
or:
do_something(hdmi->soc_data->some_feature_value);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 15/27] gpu: host1x: Add support for Tegra114
On 10/12/2013 05:24 AM, Thierry Reding wrote: > On Fri, Oct 11, 2013 at 04:13:07PM -0600, Stephen Warren wrote: >> On 10/07/2013 02:34 AM, Thierry Reding wrote: >>> Tegra114 uses a slightly updated version of host1x with an >>> additional syncpoint. >> >>> drivers/gpu/host1x/hw/host1x02.c| 42 + >>> drivers/gpu/host1x/hw/host1x02.h| 26 +++ >>> drivers/gpu/host1x/hw/hw_host1x02_channel.h | 121 >>> ++ drivers/gpu/host1x/hw/hw_host1x02_sync.h| >>> 243 >>> drivers/gpu/host1x/hw/hw_host1x02_uclass.h | 175 >>> >> >> That seems like an awful lot of extra lines to support just one >> extra syncpoint. Are there other changes? If not, can the code >> be shared/parameterized somehow? > > Yeah, I don't like very much how this is currently done. I mean > about half of this is actually duplicate code because of the static > inline functions used for register defines. As discussed elsewhere > this was originally meant to be used for coverage testing, but > nobody's done anything like that as far as I know. I'm also not > convinced that these would be very useful in coverage testing, but > adding Terje on Cc and unless he or anyone else has any (strong) > objections I'll go and remove the duplicate definitions and while > at it see if I can come up with a way to share more > code/definitions between versions of host1x. > > Do you see this as a blocker for 3.13 or can I do the cleanup > after that? As far as I know Tegra124 has a more heavily modified > version of host1x so implementing Tegra124 support might be a good > opportunity to clean this up anyway. I guess I'm unsure re: whether it's a blocker. It's certainly not some kind of ABI issue, so it's not like it forces our hand later; we can easily refactor the code later. However, I'm slightly worried that if we do actually intend to do that, it'll be seen as code-churn. Still, I guess if the main DRM maintainers don't object to this, I'm OK with it. Re: Terje's points, we (e.g. Terje) should work with the HW designers to stop moving things about, so we don't have incompatible HW. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 16/27] drm/tegra: Add Tegra114 display controller support
On 10/12/2013 05:32 AM, Thierry Reding wrote: > On Fri, Oct 11, 2013 at 04:14:27PM -0600, Stephen Warren wrote: >> On 10/07/2013 02:34 AM, Thierry Reding wrote: >>> From: Mikko Perttunen >>> >>> The Tegra114 display controller is backwards-compatible with >>> previous generations of the Tegra SoC. No code changes are >>> required. >> >> If the HW is backwards-compatible, then there's no need to add >> extra compatible values to the driver; just write the following >> in the DT, and it'll just work: >> >> compatible = "nvidia,tegra114-dc", "nvidia,tegra30-dc"; > > One reason why I thought it might be useful to still include this, > even though unnecessary, was to match it to the host1x_drm_subdevs > table. We can probably remove the entry from there as well, > though. > > As far as I can tell, the same holds for Tegra30, which is also > backwards compatible with Tegra20 but the DTS doesn't contain the > Tegra20 compatible. So to keep ABI compatibility we'll need to keep > the nvidia,tegra30-dc in the driver's match tables, but I could > still update the DTS to include the nvidia,tegra20-dc for > correctness. > > Does that make sense? Yes, fixing the Tegra30 .dtsi file sounds like a good idea. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon: stop the leaks in cik_ib_test
On Mon, Oct 14, 2013 at 5:32 AM, Christian König
wrote:
> From: Christian König
>
> Stop leaking IB memory and scratch register space when the test fails.
>
> Signed-off-by: Christian König
Both patches applied.
Thanks!
Alex
> ---
> drivers/gpu/drm/radeon/cik.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
> index b874ccd..8f393df 100644
> --- a/drivers/gpu/drm/radeon/cik.c
> +++ b/drivers/gpu/drm/radeon/cik.c
> @@ -3182,6 +3182,7 @@ int cik_ib_test(struct radeon_device *rdev, struct
> radeon_ring *ring)
> r = radeon_ib_get(rdev, ring->idx, &ib, NULL, 256);
> if (r) {
> DRM_ERROR("radeon: failed to get ib (%d).\n", r);
> + radeon_scratch_free(rdev, scratch);
> return r;
> }
> ib.ptr[0] = PACKET3(PACKET3_SET_UCONFIG_REG, 1);
> @@ -3198,6 +3199,8 @@ int cik_ib_test(struct radeon_device *rdev, struct
> radeon_ring *ring)
> r = radeon_fence_wait(ib.fence, false);
> if (r) {
> DRM_ERROR("radeon: fence wait failed (%d).\n", r);
> + radeon_scratch_free(rdev, scratch);
> + radeon_ib_free(rdev, &ib);
> return r;
> }
> for (i = 0; i < rdev->usec_timeout; i++) {
> --
> 1.8.1.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFCv2 12/13] drm: Atomic modeset ioctl
From: Ville Syrjälä
The atomic modeset ioctl cna be used to push any number of new values
for object properties. The driver can then check the full device
configuration as single unit, and try to apply the changes atomically.
The ioctl simply takes a list of object IDs and property IDs and their
values. For setting values to blob properties, the property value
indicates the length of the data, and the actual data is passed via
another blob pointer.
The caller can demand non-blocking operation from the ioctl, and if the
driver can't satisfy that requirement an error will be returned.
The caller can also request to receive asynchronous completion events
after the operation has reached the hardware. An event is sent for each
object specified by the caller, whether or not the actual state of
that object changed. Each event also carries a framebuffer ID, which
indicates to user space that the specified object is no longer
accessing that framebuffer.
TODO: detailed error reporting?
v1: original
v2: rebase on uapi changes, and drm state structs.. -- Rob Clark
v3: rebase, missing padding in drm_event_atomic.. -- Rob Clark
v4: drop atomic event, align flags w/ pageflip (atomic flags should be
a strick superset of pageflip flags to keep things easier for the
drivers)
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 157 +++-
drivers/gpu/drm/drm_drv.c | 1 +
include/drm/drmP.h | 6 ++
include/drm/drm_crtc.h | 2 +
include/uapi/drm/drm.h | 12
include/uapi/drm/drm_mode.h | 22 +++
6 files changed, 199 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 1091d82..9044bdb 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3911,7 +3911,8 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
return -EINVAL;
crtc = obj_to_crtc(obj);
- state = dev->driver->atomic_begin(dev, page_flip->flags);
+ state = dev->driver->atomic_begin(dev,
+ page_flip->flags | DRM_MODE_ATOMIC_NONBLOCK);
if (IS_ERR(state))
return PTR_ERR(state);
@@ -4324,3 +4325,157 @@ void drm_mode_config_cleanup(struct drm_device *dev)
idr_destroy(&dev->mode_config.crtc_idr);
}
EXPORT_SYMBOL(drm_mode_config_cleanup);
+
+int drm_mode_atomic_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *file_priv)
+{
+ struct drm_mode_atomic *arg = data;
+ uint32_t __user *objs_ptr = (uint32_t __user *)(unsigned
long)(arg->objs_ptr);
+ uint32_t __user *count_props_ptr = (uint32_t __user *)(unsigned
long)(arg->count_props_ptr);
+ uint32_t __user *props_ptr = (uint32_t __user *)(unsigned
long)(arg->props_ptr);
+ uint64_t __user *prop_values_ptr = (uint64_t __user *)(unsigned
long)(arg->prop_values_ptr);
+ uint64_t __user *blob_values_ptr = (uint64_t __user *)(unsigned
long)(arg->blob_values_ptr);
+ unsigned int copied_objs = 0;
+ unsigned int copied_props = 0;
+ unsigned int copied_blobs = 0;
+ void *state;
+ int ret = 0;
+ unsigned int i, j;
+
+ if (arg->flags & ~DRM_MODE_ATOMIC_FLAGS)
+ return -EINVAL;
+
+ /* can't test and expect an event at the same time. */
+ if ((arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) &&
+ (arg->flags & DRM_MODE_PAGE_FLIP_EVENT))
+ return -EINVAL;
+
+ state = dev->driver->atomic_begin(dev, arg->flags);
+ if (IS_ERR(state)) {
+ ret = PTR_ERR(state);
+ goto out;
+ }
+
+ for (i = 0; i < arg->count_objs; i++) {
+ uint32_t obj_id, count_props;
+ struct drm_mode_object *obj;
+
+ if (get_user(obj_id, objs_ptr + copied_objs)) {
+ ret = -EFAULT;
+ goto out;
+ }
+
+ obj = drm_mode_object_find(dev, obj_id, DRM_MODE_OBJECT_ANY);
+ if (!obj || !obj->properties) {
+ ret = -ENOENT;
+ goto out;
+ }
+
+ if ((obj->type == DRM_MODE_OBJECT_CRTC) &&
+ (arg->flags & DRM_MODE_PAGE_FLIP_EVENT)) {
+ struct drm_pending_vblank_event *e =
+ create_vblank_event(dev, file_priv,
arg->user_data);
+ if (!e) {
+ ret = -ENOMEM;
+ goto out;
+ }
+ ret = dev->driver->atomic_set_event(dev, state, obj, e);
+ if (ret) {
+ destroy_vblank_event(dev, file_priv, e);
+ goto out;
+ }
+ }
+
+ if (get_user(count_props, count_props_ptr + copied_objs)) {
+
[RFCv2 13/13] drm/msm: add atomic support
TODO: probably can split this up into prep patch which splits the
msm_queue_fence_cb out of gem..
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/mdp4/mdp4_crtc.c | 41 --
drivers/gpu/drm/msm/mdp4/mdp4_kms.c | 6 ++
drivers/gpu/drm/msm/mdp4/mdp4_kms.h | 1 +
drivers/gpu/drm/msm/msm_atomic.c | 146 +++
drivers/gpu/drm/msm/msm_drv.c| 22 +-
drivers/gpu/drm/msm/msm_drv.h| 8 ++
drivers/gpu/drm/msm/msm_gem.c| 24 +-
drivers/gpu/drm/msm/msm_gem.h| 13
9 files changed, 216 insertions(+), 46 deletions(-)
create mode 100644 drivers/gpu/drm/msm/msm_atomic.c
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index e5fa12b..f7648d1 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -18,6 +18,7 @@ msm-y := \
mdp4/mdp4_irq.o \
mdp4/mdp4_kms.o \
mdp4/mdp4_plane.o \
+ msm_atomic.o \
msm_drv.o \
msm_fb.o \
msm_gem.o \
diff --git a/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c
b/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c
index 1cc8a72..a88343c 100644
--- a/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/mdp4/mdp4_crtc.c
@@ -51,7 +51,6 @@ struct mdp4_crtc {
/* if there is a pending flip, these will be non-null: */
struct drm_pending_vblank_event *event;
- struct msm_fence_cb pageflip_cb;
/* the fb that we currently hold a scanout ref to: */
struct drm_framebuffer *fb;
@@ -112,12 +111,16 @@ static void complete_flip(struct drm_crtc *crtc, bool
canceled)
spin_unlock_irqrestore(&dev->event_lock, flags);
}
-static void crtc_flush(struct drm_crtc *crtc)
+void mdp4_crtc_flush(struct drm_crtc *crtc)
{
+ struct msm_drm_private *priv = crtc->dev->dev_private;
struct mdp4_crtc *mdp4_crtc = to_mdp4_crtc(crtc);
struct mdp4_kms *mdp4_kms = get_kms(crtc);
uint32_t i, flush = 0;
+ if (priv->pending_crtcs & (1 << crtc->id))
+ return;
+
for (i = 0; i < ARRAY_SIZE(mdp4_crtc->planes); i++) {
struct drm_plane *plane = mdp4_crtc->planes[i];
if (plane) {
@@ -132,19 +135,6 @@ static void crtc_flush(struct drm_crtc *crtc)
mdp4_write(mdp4_kms, REG_MDP4_OVERLAY_FLUSH, flush);
}
-static void pageflip_cb(struct msm_fence_cb *cb)
-{
- struct mdp4_crtc *mdp4_crtc =
- container_of(cb, struct mdp4_crtc, pageflip_cb);
- struct drm_crtc *crtc = &mdp4_crtc->base;
-
- mdp4_plane_set_scanout(mdp4_crtc->plane, crtc->fb);
- crtc_flush(crtc);
-
- /* enable vblank to complete flip: */
- mdp4_irq_register(get_kms(crtc), &mdp4_crtc->vblank);
-}
-
static void unref_fb_worker(struct drm_flip_work *work, void *val)
{
struct mdp4_crtc *mdp4_crtc =
@@ -354,7 +344,7 @@ static void mdp4_crtc_prepare(struct drm_crtc *crtc)
static void mdp4_crtc_commit(struct drm_crtc *crtc)
{
mdp4_crtc_dpms(crtc, DRM_MODE_DPMS_ON);
- crtc_flush(crtc);
+ mdp4_crtc_flush(crtc);
/* drop the ref to mdp clk's that we got in prepare: */
mdp4_disable(get_kms(crtc));
}
@@ -385,19 +375,22 @@ static int mdp4_crtc_page_flip(struct drm_crtc *crtc,
{
struct mdp4_crtc *mdp4_crtc = to_mdp4_crtc(crtc);
struct drm_device *dev = crtc->dev;
- struct drm_gem_object *obj;
if (mdp4_crtc->event) {
dev_err(dev->dev, "already pending flip!\n");
return -EBUSY;
}
- obj = msm_framebuffer_bo(new_fb, 0);
-
mdp4_crtc->event = event;
update_fb(crtc, true, new_fb);
- return msm_gem_queue_inactive_cb(obj, &mdp4_crtc->pageflip_cb);
+ mdp4_plane_set_scanout(mdp4_crtc->plane, crtc->fb);
+ mdp4_crtc_flush(crtc);
+
+ /* enable vblank to complete flip: */
+ mdp4_irq_register(get_kms(crtc), &mdp4_crtc->vblank);
+
+ return 0;
}
static int mdp4_crtc_set_property(struct drm_crtc *crtc, void *state,
@@ -564,8 +557,8 @@ static void mdp4_crtc_err_irq(struct mdp4_irq *irq,
uint32_t irqstatus)
{
struct mdp4_crtc *mdp4_crtc = container_of(irq, struct mdp4_crtc, err);
struct drm_crtc *crtc = &mdp4_crtc->base;
- DBG("%s: error: %08x", mdp4_crtc->name, irqstatus);
- crtc_flush(crtc);
+ DRM_ERROR("%s: error: %08x\n", mdp4_crtc->name, irqstatus);
+ mdp4_crtc_flush(crtc);
}
uint32_t mdp4_crtc_vblank(struct drm_crtc *crtc)
@@ -644,7 +637,7 @@ static void set_attach(struct drm_crtc *crtc, enum
mdp4_pipe pipe_id,
mdp4_crtc->planes[pipe_id] = plane;
blend_setup(crtc);
if (mdp4_crtc->enabled && (plane != mdp4_crtc->plane))
- crtc_flush(crtc);
+ mdp4_crtc_flush(crtc);
}
void mdp4_crtc_attach(struct drm_crtc *crtc, struct drm_plane *plane)
@@ -702,8 +695,6 @@ struct drm_crtc *mdp4_crtc_init(struct drm_device *dev,
ret = drm_fli
[RFCv2 11/13] drm: convert crtc to properties/state
Break the mutable state of a crtc out into a separate structure
and use atomic properties mechanism to set crtc attributes. This
makes it easier to have some helpers for crtc->set_property()
and for checking for invalid params. The idea is that individual
drivers can wrap the state struct in their own struct which adds
driver specific parameters, for easy build-up of state across
multiple set_property() calls and for easy atomic commit or roll-
back.
---
drivers/gpu/drm/ast/ast_mode.c | 1 +
drivers/gpu/drm/cirrus/cirrus_mode.c | 1 +
drivers/gpu/drm/drm_atomic_helper.c| 249 +++-
drivers/gpu/drm/drm_crtc.c | 458 +++--
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 5 +-
drivers/gpu/drm/gma500/cdv_intel_display.c | 1 +
drivers/gpu/drm/gma500/psb_intel_display.c | 1 +
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/mgag200/mgag200_mode.c | 1 +
drivers/gpu/drm/msm/mdp4/mdp4_crtc.c | 5 +-
drivers/gpu/drm/nouveau/dispnv04/crtc.c| 1 +
drivers/gpu/drm/nouveau/nv50_display.c | 1 +
drivers/gpu/drm/omapdrm/omap_crtc.c| 9 +-
drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
drivers/gpu/drm/qxl/qxl_display.c | 2 +
drivers/gpu/drm/radeon/radeon_display.c| 2 +
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 2 +
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 +
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 1 +
drivers/gpu/drm/udl/udl_modeset.c | 2 +
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c| 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 +
drivers/gpu/host1x/drm/dc.c| 1 +
drivers/staging/imx-drm/ipuv3-crtc.c | 1 +
include/drm/drm_atomic_helper.h| 37 +++
include/drm/drm_crtc.h | 77 -
26 files changed, 627 insertions(+), 238 deletions(-)
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 7fc9f72..13f6943 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -619,6 +619,7 @@ static const struct drm_crtc_funcs ast_crtc_funcs = {
.cursor_move = ast_cursor_move,
.reset = ast_crtc_reset,
.set_config = drm_crtc_helper_set_config,
+ .set_property = drm_atomic_helper_crtc_set_property,
.gamma_set = ast_crtc_gamma_set,
.destroy = ast_crtc_destroy,
};
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index 60685b2..2d8b4ce 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -363,6 +363,7 @@ static void cirrus_crtc_destroy(struct drm_crtc *crtc)
static const struct drm_crtc_funcs cirrus_crtc_funcs = {
.gamma_set = cirrus_crtc_gamma_set,
.set_config = drm_crtc_helper_set_config,
+ .set_property = drm_atomic_helper_crtc_set_property,
.destroy = cirrus_crtc_destroy,
};
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 0618113..91b7580 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -40,11 +40,13 @@ void *drm_atomic_helper_begin(struct drm_device *dev,
uint32_t flags)
{
struct drm_atomic_helper_state *state;
int nplanes = dev->mode_config.num_plane;
+ int ncrtcs = dev->mode_config.num_crtc;
int sz;
void *ptr;
sz = sizeof(*state);
sz += (sizeof(state->planes) + sizeof(state->pstates)) * nplanes;
+ sz += (sizeof(state->crtcs) + sizeof(state->cstates)) * ncrtcs;
ptr = kzalloc(sz, GFP_KERNEL);
@@ -61,6 +63,12 @@ void *drm_atomic_helper_begin(struct drm_device *dev,
uint32_t flags)
state->pstates = ptr;
ptr = &state->pstates[nplanes];
+ state->crtcs = ptr;
+ ptr = &state->crtcs[ncrtcs];
+
+ state->cstates = ptr;
+ ptr = &state->cstates[ncrtcs];
+
return state;
}
EXPORT_SYMBOL(drm_atomic_helper_begin);
@@ -79,7 +87,16 @@ int drm_atomic_helper_set_event(struct drm_device *dev,
void *state, struct drm_mode_object *obj,
struct drm_pending_vblank_event *event)
{
- return -EINVAL; /* for now */
+ switch (obj->type) {
+ case DRM_MODE_OBJECT_CRTC: {
+ struct drm_crtc_state *cstate =
+ drm_atomic_get_crtc_state(obj_to_crtc(obj), state);
+ cstate->event = event;
+ return 0;
+ }
+ default:
+ return -EINVAL;
+ }
}
EXPORT_SYMBOL(drm_atomic_helper_set_event);
@@ -98,6 +115,7 @@ int drm_atomic_helper_check(struct drm_device *dev, void
*state)
{
struct drm_atomic_helper_state *a = state;
int nplanes = dev->mode_config.num_plane;
+ int ncrtcs = dev->mode_config.num_crtc;
int i, ret = 0;
for (i = 0; i < nplanes; i++) {
@@ -108,6 +126,14 @@ int drm_atomic_helper_ch
[RFCv2 10/13] drm: convert plane to properties/state
Break the mutable state of a plane out into a separate structure
and use atomic properties mechanism to set plane attributes. This
makes it easier to have some helpers for plane->set_property()
and for checking for invalid params. The idea is that individual
drivers can wrap the state struct in their own struct which adds
driver specific parameters, for easy build-up of state across
multiple set_property() calls and for easy atomic commit or roll-
back.
The same should be done for CRTC, encoder, and connector, but this
patch only includes the first part (plane).
---
drivers/gpu/drm/drm_atomic_helper.c | 137 +-
drivers/gpu/drm/drm_crtc.c | 399 +++-
drivers/gpu/drm/drm_fb_helper.c | 17 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.c| 4 +-
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 6 +-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 13 +-
drivers/gpu/drm/i915/intel_sprite.c | 19 +-
drivers/gpu/drm/msm/mdp4/mdp4_crtc.c| 2 +-
drivers/gpu/drm/msm/mdp4/mdp4_plane.c | 18 +-
drivers/gpu/drm/omapdrm/omap_crtc.c | 4 +-
drivers/gpu/drm/omapdrm/omap_drv.c | 2 +-
drivers/gpu/drm/omapdrm/omap_plane.c| 30 ++-
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 5 +-
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 2 +-
drivers/gpu/drm/shmobile/shmob_drm_plane.c | 6 +-
drivers/gpu/host1x/drm/dc.c | 16 +-
include/drm/drm_atomic_helper.h | 37 ++-
include/drm/drm_crtc.h | 88 +-
18 files changed, 615 insertions(+), 190 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 46c67b8..0618113 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -39,10 +39,12 @@
void *drm_atomic_helper_begin(struct drm_device *dev, uint32_t flags)
{
struct drm_atomic_helper_state *state;
+ int nplanes = dev->mode_config.num_plane;
int sz;
void *ptr;
sz = sizeof(*state);
+ sz += (sizeof(state->planes) + sizeof(state->pstates)) * nplanes;
ptr = kzalloc(sz, GFP_KERNEL);
@@ -52,6 +54,13 @@ void *drm_atomic_helper_begin(struct drm_device *dev,
uint32_t flags)
kref_init(&state->refcount);
state->dev = dev;
state->flags = flags;
+
+ state->planes = ptr;
+ ptr = &state->planes[nplanes];
+
+ state->pstates = ptr;
+ ptr = &state->pstates[nplanes];
+
return state;
}
EXPORT_SYMBOL(drm_atomic_helper_begin);
@@ -87,7 +96,19 @@ EXPORT_SYMBOL(drm_atomic_helper_set_event);
*/
int drm_atomic_helper_check(struct drm_device *dev, void *state)
{
- return 0; /* for now */
+ struct drm_atomic_helper_state *a = state;
+ int nplanes = dev->mode_config.num_plane;
+ int i, ret = 0;
+
+ for (i = 0; i < nplanes; i++) {
+ if (a->planes[i]) {
+ ret = drm_atomic_check_plane_state(a->planes[i],
a->pstates[i]);
+ if (ret)
+ break;
+ }
+ }
+
+ return ret;
}
EXPORT_SYMBOL(drm_atomic_helper_check);
@@ -104,7 +125,19 @@ EXPORT_SYMBOL(drm_atomic_helper_check);
*/
int drm_atomic_helper_commit(struct drm_device *dev, void *state)
{
- return 0; /* for now */
+ struct drm_atomic_helper_state *a = state;
+ int nplanes = dev->mode_config.num_plane;
+ int i, ret = 0;
+
+ for (i = 0; i < nplanes; i++) {
+ if (a->planes[i]) {
+ ret = drm_atomic_commit_plane_state(a->planes[i],
a->pstates[i]);
+ if (ret)
+ break;
+ }
+ }
+
+ return ret;
}
EXPORT_SYMBOL(drm_atomic_helper_commit);
@@ -125,11 +158,111 @@ void _drm_atomic_helper_state_free(struct kref *kref)
{
struct drm_atomic_helper_state *state =
container_of(kref, struct drm_atomic_helper_state, refcount);
+ struct drm_device *dev = state->dev;
+ int nplanes = dev->mode_config.num_plane;
+ int i;
+
+ for (i = 0; i < nplanes; i++) {
+ if (state->pstates[i]) {
+ state->planes[i]->state->state = NULL;
+ kfree(state->pstates[i]);
+ }
+ }
+
kfree(state);
}
EXPORT_SYMBOL(_drm_atomic_helper_state_free);
+int drm_atomic_helper_plane_set_property(struct drm_plane *plane, void *state,
+ struct drm_property *property, uint64_t val, void *blob_data)
+{
+ return drm_plane_set_property(plane,
+ drm_atomic_get_plane_state(plane, state),
+ property, val, blob_data);
+}
+EXPORT_SYMBOL(drm_atomic_helper_plane_set_property);
+
+void drm_atomic_helper_init_plane_state(struct drm_plane *plane,
+ struct drm_plane_state *pstate, void *state
[RFCv2 09/13] drm: Refactor object property check code
From: Ville Syrjälä
Refactor the code to check whether an object has a specific property
to a new function.
v1: original
v2: rebase on atomic -- Rob Clark
v3: EINVAL->ENOENT
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index da641fb..9f46f3b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3375,6 +3375,19 @@ static int drm_mode_set_obj_prop(struct drm_mode_object
*obj,
return -EINVAL;
}
+static bool object_has_prop(const struct drm_mode_object *obj, u32 prop_id)
+{
+ int i;
+
+ if (!obj->properties)
+ return false;
+
+ for (i = 0; i < obj->properties->count; i++)
+ if (obj->properties->ids[i] == prop_id)
+ return true;
+ return false;
+}
+
/* call with mode_config mutex held */
static int drm_mode_set_obj_prop_id(struct drm_device *dev, void *state,
uint32_t obj_id, uint32_t obj_type,
@@ -3383,20 +3396,10 @@ static int drm_mode_set_obj_prop_id(struct drm_device
*dev, void *state,
struct drm_mode_object *arg_obj;
struct drm_mode_object *prop_obj;
struct drm_property *property;
- int i;
arg_obj = drm_mode_object_find(dev, obj_id, obj_type);
- if (!arg_obj)
- return -EINVAL;
- if (!arg_obj->properties)
- return -EINVAL;
-
- for (i = 0; i < arg_obj->properties->count; i++)
- if (arg_obj->properties->ids[i] == prop_id)
- break;
-
- if (i == arg_obj->properties->count)
- return -EINVAL;
+ if (!(arg_obj && object_has_prop(arg_obj, prop_id)))
+ return -ENOENT;
prop_obj = drm_mode_object_find(dev, prop_id,
DRM_MODE_OBJECT_PROPERTY);
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFCv2 08/13] drm: Allow drm_mode_object_find() to look up an object of any type
From: Ville Syrjälä
To avoid having to pass object types from userspace for atomic mode
setting ioctl, allow drm_mode_object_find() to look up an object of any
type. This will only work as long as the all object types share the ID
space.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_crtc.c | 3 ++-
include/drm/drm_crtc.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6f72ba8..da641fb 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -360,7 +360,8 @@ struct drm_mode_object *drm_mode_object_find(struct
drm_device *dev,
mutex_lock(&dev->mode_config.idr_mutex);
obj = idr_find(&dev->mode_config.crtc_idr, id);
- if (!obj || (obj->type != type) || (obj->id != id))
+ if (!obj || (type != DRM_MODE_OBJECT_ANY && obj->type != type) ||
+ (obj->id != id))
obj = NULL;
mutex_unlock(&dev->mode_config.idr_mutex);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 372b159..8831562 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -51,6 +51,7 @@ struct drm_object_property_values;
#define DRM_MODE_OBJECT_BLOB 0x
#define DRM_MODE_OBJECT_PLANE 0x
#define DRM_MODE_OBJECT_BRIDGE 0xbdbdbdbd
+#define DRM_MODE_OBJECT_ANY 0
struct drm_mode_object {
uint32_t id;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFCv2 07/13] drm: split propvals out and blob property support
Split property values out into a different struct, so we can later
move property values into state structs. This will allow the
property values to stay in sync w/ the state updates which are
either discarded or atomically committed.
And since we are touching all the same code, add support for mutable
blob properties, which will also be needed for atomic modeset.
---
drivers/gpu/drm/drm_crtc.c | 79 +
drivers/gpu/drm/drm_fb_helper.c | 3 +-
drivers/gpu/drm/gma500/cdv_intel_dp.c | 3 +-
drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 3 +-
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 6 ++-
drivers/gpu/drm/gma500/mdfld_dsi_output.c | 8 +--
drivers/gpu/drm/gma500/psb_intel_lvds.c | 6 ++-
drivers/gpu/drm/gma500/psb_intel_sdvo.c | 19 +--
drivers/gpu/drm/i2c/ch7006_drv.c| 4 +-
drivers/gpu/drm/i915/intel_display.c| 3 +-
drivers/gpu/drm/i915/intel_dp.c | 3 +-
drivers/gpu/drm/i915/intel_hdmi.c | 3 +-
drivers/gpu/drm/i915/intel_sdvo.c | 19 +--
drivers/gpu/drm/i915/intel_tv.c | 6 ++-
drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 3 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 4 +-
drivers/gpu/drm/omapdrm/omap_drv.c | 6 ++-
drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 3 +-
drivers/gpu/drm/rcar-du/rcar_du_vgacon.c| 3 +-
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 4 +-
include/drm/drm_crtc.h | 11 +++-
21 files changed, 142 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index bf7a44b..6f72ba8 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -90,6 +90,14 @@ void drm_warn_on_modeset_not_all_locked(struct drm_device
*dev)
}
EXPORT_SYMBOL(drm_warn_on_modeset_not_all_locked);
+static int drm_mode_set_obj_prop(struct drm_mode_object *obj,
+ void *state, struct drm_property *property,
+ uint64_t value, void *blob_data);
+static struct drm_property_blob *drm_property_create_blob(struct drm_device
*dev,
+ int length, void *data);
+static void drm_property_destroy_blob(struct drm_device *dev,
+ struct drm_property_blob *blob);
+
/* Avoid boilerplate. I'm tired of typing. */
#define DRM_ENUM_NAME_FN(fnname, list) \
const char *fnname(int val) \
@@ -640,6 +648,7 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc
*crtc,
goto out;
crtc->base.properties = &crtc->properties;
+ crtc->base.propvals = &crtc->propvals;
list_add_tail(&crtc->head, &dev->mode_config.crtc_list);
dev->mode_config.num_crtc++;
@@ -729,6 +738,7 @@ int drm_connector_init(struct drm_device *dev,
goto out;
connector->base.properties = &connector->properties;
+ connector->base.propvals = &connector->propvals;
connector->dev = dev;
connector->funcs = funcs;
connector->connector_type = connector_type;
@@ -902,6 +912,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane
*plane,
goto out;
plane->base.properties = &plane->properties;
+ plane->base.propvals = &plane->propvals;
plane->dev = dev;
plane->funcs = funcs;
plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
@@ -1688,7 +1699,7 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
goto out;
}
- if (put_user(connector->properties.values[i],
+ if (put_user(connector->propvals.values[i],
prop_values + copied)) {
ret = -EFAULT;
goto out;
@@ -2969,19 +2980,33 @@ void drm_object_attach_property(struct drm_mode_object
*obj,
}
obj->properties->ids[count] = property->base.id;
- obj->properties->values[count] = init_val;
+ obj->propvals->values[count] = init_val;
obj->properties->count++;
}
EXPORT_SYMBOL(drm_object_attach_property);
int drm_object_property_set_value(struct drm_mode_object *obj,
- struct drm_property *property, uint64_t val)
+ struct drm_object_property_values *propvals,
+ struct drm_property *property, uint64_t val,
+ void *blob_data)
{
int i;
for (i = 0; i < obj->properties->count; i++) {
if (obj->properties->ids[i] == property->base.id) {
- obj->properties->values[i] = val;
+ struct drm_device *dev = property->dev;
+ if (property->flags & DRM_MODE_PROP_BLOB) {
+ struct drm_property_blob *bl
[RFCv2 06/13] drm: helpers to find mode objects
Lifted from Russell King's armada drm driver, plus a couple others
added.
---
include/drm/drm_crtc.h | 40
1 file changed, 40 insertions(+)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e042d12..0ea61b3 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1067,6 +1067,46 @@ drm_property_get_obj(struct drm_property *property,
uint64_t value)
return drm_mode_object_find(property->dev, value, property->values[0]);
}
+static inline struct drm_plane *drm_plane_find(struct drm_device *dev,
+ uint32_t id)
+{
+ struct drm_mode_object *mo;
+ mo = drm_mode_object_find(dev, id, DRM_MODE_OBJECT_PLANE);
+ return mo ? obj_to_plane(mo) : NULL;
+}
+
+static inline struct drm_crtc *drm_crtc_find(struct drm_device *dev,
+ uint32_t id)
+{
+ struct drm_mode_object *mo;
+ mo = drm_mode_object_find(dev, id, DRM_MODE_OBJECT_CRTC);
+ return mo ? obj_to_crtc(mo) : NULL;
+}
+
+static inline struct drm_encoder *drm_encoder_find(struct drm_device *dev,
+ uint32_t id)
+{
+ struct drm_mode_object *mo;
+ mo = drm_mode_object_find(dev, id, DRM_MODE_OBJECT_ENCODER);
+ return mo ? obj_to_encoder(mo) : NULL;
+}
+
+static inline struct drm_connector *drm_connector_find(struct drm_device *dev,
+ uint32_t id)
+{
+ struct drm_mode_object *mo;
+ mo = drm_mode_object_find(dev, id, DRM_MODE_OBJECT_CONNECTOR);
+ return mo ? obj_to_connector(mo) : NULL;
+}
+
+static inline struct drm_property_blob *
+drm_property_blob_find(struct drm_device *dev, uint32_t id)
+{
+ struct drm_mode_object *mo;
+ mo = drm_mode_object_find(dev, id, DRM_MODE_OBJECT_BLOB);
+ return mo ? obj_to_blob(mo) : NULL;
+}
+
/* IOCTLs */
extern int drm_mode_getresources(struct drm_device *dev,
void *data, struct drm_file *file_priv);
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFCv2 05/13] drm: add DRM_MODE_PROP_SIGNED property flag
Flag for range property types indicating that the value is a signed
integer rather than unsigned. For range properties, the signed flag
will trigger use of signed integer comparisions, to handle negative
values properly.
---
drivers/gpu/drm/drm_crtc.c | 15 +++
include/drm/drm_crtc.h | 9 +
include/uapi/drm/drm_mode.h | 2 ++
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 471cf16..bf7a44b 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3211,11 +3211,18 @@ EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
static bool drm_property_change_is_valid(struct drm_property *property,
uint64_t value)
{
- if (property->flags & DRM_MODE_PROP_IMMUTABLE)
+ if (property->flags & DRM_MODE_PROP_IMMUTABLE) {
return false;
- if (property->flags & DRM_MODE_PROP_RANGE) {
- if (value < property->values[0] || value > property->values[1])
- return false;
+ } else if (property->flags & DRM_MODE_PROP_RANGE) {
+ if (property->flags & DRM_MODE_PROP_SIGNED) {
+ int64_t svalue = U642I64(value);
+ if (svalue < U642I64(property->values[0]) ||
+ svalue > U642I64(property->values[1]))
+ return false;
+ } else {
+ if (value < property->values[0] || value >
property->values[1])
+ return false;
+ }
return true;
} else if (property->flags & DRM_MODE_PROP_BITMASK) {
int i;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 77c8f11..e042d12 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -64,6 +64,15 @@ struct drm_object_properties {
uint64_t values[DRM_OBJECT_MAX_PROPERTY];
};
+static inline int64_t U642I64(uint64_t val)
+{
+ return (int64_t)*((int64_t *)&val);
+}
+static inline uint64_t I642U64(int64_t val)
+{
+ return (uint64_t)*((uint64_t *)&val);
+}
+
/*
* Note on terminology: here, for brevity and convenience, we refer to
connector
* control chips as 'CRTCs'. They can control any type of connector, VGA,
LVDS,
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 15db837..6d4f089 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -241,6 +241,8 @@ struct drm_mode_get_connector {
* be changed dynamically, assuming the pixel format does not change.
*/
#define DRM_MODE_PROP_DYNAMIC (1<<24)
+/* Indicates that numeric property values are signed rather than unsigned: */
+#define DRM_MODE_PROP_SIGNED (1<<25)
struct drm_mode_property_enum {
__u64 value;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFCv2 04/13] drm: add DRM_MODE_PROP_DYNAMIC property flag
This indicates to userspace that the property is something that can
be set dynamically without requiring a "test" step to check if the
hw is capable. This allows a userspace compositor, such as weston,
to avoid an extra ioctl to check whether it needs to fall-back to
GPU to composite some surface prior to submission of GPU render
commands.
---
include/uapi/drm/drm_mode.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 35921ba..15db837 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -232,6 +232,15 @@ struct drm_mode_get_connector {
#define DRM_MODE_PROP_BLOB (1<<4)
#define DRM_MODE_PROP_BITMASK (1<<5) /* bitmask of enumerated types */
#define DRM_MODE_PROP_OBJECT (1<<6) /* drm mode object */
+/* Properties that are not dynamic cannot safely be changed without a
+ * atomic-modeset / atomic-pageflip test step. But if userspace is
+ * only changing dynamic properties, it is guaranteed that the change
+ * will not exceed hw limits, so no test step is required.
+ *
+ * Note that fb_id properties are a bit ambiguous.. they of course can
+ * be changed dynamically, assuming the pixel format does not change.
+ */
+#define DRM_MODE_PROP_DYNAMIC (1<<24)
struct drm_mode_property_enum {
__u64 value;
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFCv2 03/13] drm: add object property type
An object property is an id (idr) for a drm mode object. This
will allow a property to be used set/get a framebuffer, CRTC, etc.
---
drivers/gpu/drm/drm_crtc.c | 34 ++
include/drm/drm_crtc.h | 10 ++
include/uapi/drm/drm_mode.h | 1 +
3 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f2a6d72..471cf16 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2776,6 +2776,8 @@ struct drm_property *drm_property_create(struct
drm_device *dev, int flags,
if (!property)
return NULL;
+ property->dev = dev;
+
if (num_values) {
property->values = kzalloc(sizeof(uint64_t)*num_values,
GFP_KERNEL);
if (!property->values)
@@ -2879,6 +2881,23 @@ struct drm_property *drm_property_create_range(struct
drm_device *dev, int flags
}
EXPORT_SYMBOL(drm_property_create_range);
+struct drm_property *drm_property_create_object(struct drm_device *dev,
+int flags, const char *name, uint32_t
type)
+{
+ struct drm_property *property;
+
+ flags |= DRM_MODE_PROP_OBJECT;
+
+ property = drm_property_create(dev, flags, name, 1);
+ if (!property)
+ return NULL;
+
+ property->values[0] = type;
+
+ return property;
+}
+EXPORT_SYMBOL(drm_property_create_object);
+
int drm_property_add_enum(struct drm_property *property, int index,
uint64_t value, const char *name)
{
@@ -3207,6 +3226,11 @@ static bool drm_property_change_is_valid(struct
drm_property *property,
} else if (property->flags & DRM_MODE_PROP_BLOB) {
/* Only the driver knows */
return true;
+ } else if (property->flags & DRM_MODE_PROP_OBJECT) {
+ /* a zero value for an object property translates to null: */
+ if (value == 0)
+ return true;
+ return drm_property_get_obj(property, value) != NULL;
} else {
int i;
for (i = 0; i < property->num_values; i++)
@@ -3283,9 +3307,9 @@ static int drm_mode_plane_set_obj_prop(struct drm_plane
*plane,
return ret;
}
-static int drm_mode_set_obj_prop(struct drm_device *dev,
- struct drm_mode_object *obj, void *state,
- struct drm_property *property, uint64_t value, void *blob_data)
+static int drm_mode_set_obj_prop(struct drm_mode_object *obj,
+ void *state, struct drm_property *property,
+ uint64_t value, void *blob_data)
{
if (drm_property_change_is_valid(property, value)) {
switch (obj->type) {
@@ -3299,6 +3323,8 @@ static int drm_mode_set_obj_prop(struct drm_device *dev,
return drm_mode_plane_set_obj_prop(obj_to_plane(obj),
state, property, value, blob_data);
}
+ } else {
+ DRM_DEBUG("invalid value: %s = %llx\n", property->name, value);
}
return -EINVAL;
@@ -,7 +3359,7 @@ static int drm_mode_set_obj_prop_id(struct drm_device
*dev, void *state,
return -EINVAL;
property = obj_to_property(prop_obj);
- return drm_mode_set_obj_prop(dev, arg_obj, state, property,
+ return drm_mode_set_obj_prop(arg_obj, state, property,
value, blob_data);
}
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index ad4e1ce..77c8f11 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -297,6 +297,7 @@ struct drm_property {
char name[DRM_PROP_NAME_LEN];
uint32_t num_values;
uint64_t *values;
+ struct drm_device *dev;
struct list_head enum_blob_list;
};
@@ -1030,6 +1031,8 @@ struct drm_property *drm_property_create_bitmask(struct
drm_device *dev,
struct drm_property *drm_property_create_range(struct drm_device *dev, int
flags,
const char *name,
uint64_t min, uint64_t max);
+struct drm_property *drm_property_create_object(struct drm_device *dev,
+int flags, const char *name, uint32_t
type);
extern void drm_property_destroy(struct drm_device *dev, struct drm_property
*property);
extern int drm_property_add_enum(struct drm_property *property, int index,
uint64_t value, const char *name);
@@ -1048,6 +1051,13 @@ extern int drm_mode_crtc_set_gamma_size(struct drm_crtc
*crtc,
int gamma_size);
extern struct drm_mode_object *drm_mode_object_find(struct drm_device *dev,
uint32_t id, uint32_t type);
+
+static inline struct drm_mode_object *
+drm_property_get_obj(struct drm_property *property, uint64_t value)
+{
+ return drm_mode_object_f
[RFCv2 01/13] HACK: disable drm for M68K.. no 8 byte get_user()
I'm not really sure if there exists any drm driver usable on m68k? --- drivers/gpu/drm/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index 95d..61db9be 100644 --- a/drivers/gpu/drm/Kconfig +++ b/drivers/gpu/drm/Kconfig @@ -7,6 +7,8 @@ menuconfig DRM tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)" depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA + # exclude M68K for now, since it doesn't have 8 byte get_user() + depends on !M68K select HDMI select I2C select I2C_ALGOBIT -- 1.8.3.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFCv2 00/13] Atomic/nuclear modeset/pageflip
This patchset is the merging of Ville's atomic modeset ioctl, and
the drm_{crtc,plane}_state stuff from my original nuclear pageflip
RFC.
It is currently working on msm with an updated version of Ville's
glplane test app (removing cursor properties and atomic event):
https://github.com/robclark/glplane
the libdrm bits can be found here:
https://github.com/robclark/libdrm/commits/atomic
The msm part is on top of msm-next, the complete branch can be found:
http://cgit.freedesktop.org/~robclark/linux/log/?h=global-thermonuclear-war-3
Compared to my earlier nuclear pageflip RFC, there is now a set of
drm_atomic helpers which do most of the non-hw-specific work for
the different drivers.
Unlike the crtc helpers, it is intended that the atomic helpers can
be used piecemeal by the drivers, either using all or overriding
parts as needed.
A naive driver, with no special constraints or hw support for atomic
updates may simply add the following to their driver struct:
.atomic_begin = drm_atomic_helper_begin,
.atomic_set_event = drm_atomic_helper_set_event,
.atomic_check = drm_atomic_helper_check,
.atomic_commit= drm_atomic_helper_commit,
.atomic_end = drm_atomic_helper_end,
.atomic_helpers = &drm_atomic_helper_funcs,
In addition, if you're plane/crtc doesn't already have it's own
custom properties, then add to your plane/crtc_funcs:
.set_property = drm_atomic_helper_{plane,crtc}_set_property,
A driver which can have (for example) conflicting modes across
multiple crtcs (for example, bandwidth limitations or clock/pll
configuration restrictions), can wrap drm_atomic_helper_check()
with their own driver specific .atomic_check() function.
A driver which can support true atomic updates can wrap
drm_atomic_helper_commit().
A driver with custom properties should override the appropriate
get_state(), check_state(), and commit_state() functions in
.atomic_helpers if it uses the drm-atomic-helpers. Otherwise it
is free to use &drm_atomic_helper_funcs as-is.
TODO:
* revisit fb refcnting.. it currently works but likely would have
problems if userspace set fb_id property on an object multiple
times in an atomic ioctl, which would be solved if the state
object also held a ref to the fb
* convert locking to ww_mutex? I was initially hoping to get
by without this, but I'm starting to suspect that it will
make the locking easier to get correct
* fix drivers with custom plane or crtc properties
Rob Clark (10):
HACK: disable drm for M68K.. no 8 byte get_user()
drm: add atomic fxns
drm: add object property type
drm: add DRM_MODE_PROP_DYNAMIC property flag
drm: add DRM_MODE_PROP_SIGNED property flag
drm: helpers to find mode objects
drm: split propvals out and blob property support
drm: convert plane to properties/state
drm: convert crtc to properties/state
drm/msm: add atomic support
Ville Syrjälä (3):
drm: Allow drm_mode_object_find() to look up an object of any type
drm: Refactor object property check code
drm: Atomic modeset ioctl
drivers/gpu/drm/Kconfig |2 +
drivers/gpu/drm/Makefile|3 +-
drivers/gpu/drm/ast/ast_drv.c |6 +
drivers/gpu/drm/ast/ast_drv.h |1 +
drivers/gpu/drm/ast/ast_mode.c |1 +
drivers/gpu/drm/cirrus/cirrus_drv.c |6 +
drivers/gpu/drm/cirrus/cirrus_drv.h |1 +
drivers/gpu/drm/cirrus/cirrus_mode.c|1 +
drivers/gpu/drm/drm_atomic_helper.c | 515 +++
drivers/gpu/drm/drm_crtc.c | 1243 ++-
drivers/gpu/drm/drm_drv.c |1 +
drivers/gpu/drm/drm_fb_helper.c | 20 +-
drivers/gpu/drm/exynos/exynos_drm_crtc.c| 13 +-
drivers/gpu/drm/exynos/exynos_drm_drv.c |7 +
drivers/gpu/drm/exynos/exynos_drm_encoder.c |6 +-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 17 +-
drivers/gpu/drm/gma500/cdv_intel_crt.c |4 +-
drivers/gpu/drm/gma500/cdv_intel_display.c |1 +
drivers/gpu/drm/gma500/cdv_intel_dp.c |7 +-
drivers/gpu/drm/gma500/cdv_intel_hdmi.c |7 +-
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 10 +-
drivers/gpu/drm/gma500/mdfld_dsi_output.c | 12 +-
drivers/gpu/drm/gma500/psb_drv.c|7 +
drivers/gpu/drm/gma500/psb_drv.h|1 +
drivers/gpu/drm/gma500/psb_intel_display.c |1 +
drivers/gpu/drm/gma500/psb_intel_drv.h |4 +-
drivers/gpu/drm/gma500/psb_intel_lvds.c | 10 +-
drivers/gpu/drm/gma500/psb_intel_sdvo.c | 23 +-
drivers/gpu/drm/i2c/ch7006_drv.c|4 +-
drivers/gpu/drm/i915/i915_drv.c |8 +
drivers/gpu/drm/i915/intel_crt.c|4 +-
drivers/gpu/drm/i915/intel_display.c|4 +-
drivers/gpu/drm/i915/intel_dp.c |7 +-
drivers/gpu/drm/i915/intel_drv.h|1 +
drivers/gpu/drm/i915/intel_
[Bug 70439] Mobility 4570: System freezes after ~5s of enabling audio via xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=70439 --- Comment #11 from Alex Deucher --- Created attachment 87616 --> https://bugs.freedesktop.org/attachment.cgi?id=87616&action=edit possible fix Please try this patch and append radeon.audio=1 to the kernel command line in grub. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #38 from Marek Olšák --- This issue was fixed by the revert. Closing. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: SimpleFB drivers repository?
Hi On Mon, Oct 14, 2013 at 6:19 PM, Gary Mort wrote: > Is there a repository for the SimpleFB drivers[the DRI driver and the plain > framebuffer driver]? Which drivers are you exactly talking about? Do you have links to the patches? There're several independent projects called "simplefb". If you're talking about the simplefb fbdev driver, it's developed upstream and available since linux-3.10 (linux-fb...@vger.kernel.org ML). SimpleDRM is developed on this list and still experimental. There're no "upstream" repositories just for the drivers. Patches on the ML is all there is. > I'd like to play around with it for a project - I discovered it via a google > search which pointed me to some archived e-mails on this list - but those > e-mails just contained the patches and I'd rather just pull the latest > repository then try to locate and consolidate all the patches. For simplefb just pull Linus' tree. For simpleDRM just apply the patches. If you're talking about something else, please post some links to the patches you're talking about. Thanks David ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: compare actual vrefresh for all modes for quirks
On Mon, Oct 14, 2013 at 12:50:41PM -0400, Alex Deucher wrote:
> On Fri, Sep 20, 2013 at 6:32 PM, Alex Deucher wrote:
> > On Thu, Aug 15, 2013 at 11:48 AM, Alex Deucher
> > wrote:
> >> The vrefresh field of the mode is 0 for most modes
> >> fetched from the EDID (e.g., established timings).
> >> When dealing with monitors that have a bogus preferred
> >> mode, we may not always select the mode we want because
> >> we compare the target refresh to the mode's vrefresh which
> >> is 0 in a lot of cases.
> >>
> >> Signed-off-by: Alex Deucher
> >
> > Ping? Any objections?
>
> Anyone? Without this quirking doesn't work unless the quirked mode
> happens to have the vrefesh field filled in which most modes don't.
Yeah, seems saner than comparing against 0.
Reviewed-by: Ville Syrjälä
>
> Alex
>
>
> >
> > Alex
> >
> >> ---
> >> drivers/gpu/drm/drm_edid.c | 11 ---
> >> 1 file changed, 8 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 58b4882..c3095e0 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -1278,7 +1278,7 @@ static u32 edid_get_quirks(struct edid *edid)
> >> }
> >>
> >> #define MODE_SIZE(m) ((m)->hdisplay * (m)->vdisplay)
> >> -#define MODE_REFRESH_DIFF(m,r) (abs((m)->vrefresh - target_refresh))
> >> +#define MODE_REFRESH_DIFF(c,t) (abs((c) - (t)))
> >>
> >> /**
> >> * edid_fixup_preferred - set preferred modes based on quirk list
> >> @@ -1293,6 +1293,7 @@ static void edid_fixup_preferred(struct
> >> drm_connector *connector,
> >> {
> >> struct drm_display_mode *t, *cur_mode, *preferred_mode;
> >> int target_refresh = 0;
> >> + int cur_vrefresh, preferred_vrefresh;
> >>
> >> if (list_empty(&connector->probed_modes))
> >> return;
> >> @@ -1315,10 +1316,14 @@ static void edid_fixup_preferred(struct
> >> drm_connector *connector,
> >> if (MODE_SIZE(cur_mode) > MODE_SIZE(preferred_mode))
> >> preferred_mode = cur_mode;
> >>
> >> + cur_vrefresh = cur_mode->vrefresh ?
> >> + cur_mode->vrefresh : drm_mode_vrefresh(cur_mode);
> >> + preferred_vrefresh = preferred_mode->vrefresh ?
> >> + preferred_mode->vrefresh :
> >> drm_mode_vrefresh(preferred_mode);
> >> /* At a given size, try to get closest to target refresh */
> >> if ((MODE_SIZE(cur_mode) == MODE_SIZE(preferred_mode)) &&
> >> - MODE_REFRESH_DIFF(cur_mode, target_refresh) <
> >> - MODE_REFRESH_DIFF(preferred_mode, target_refresh)) {
> >> + MODE_REFRESH_DIFF(cur_vrefresh, target_refresh) <
> >> + MODE_REFRESH_DIFF(preferred_vrefresh, target_refresh))
> >> {
> >> preferred_mode = cur_mode;
> >> }
> >> }
> >> --
> >> 1.8.3.1
> >>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/edid: compare actual vrefresh for all modes for quirks
On Fri, Sep 20, 2013 at 6:32 PM, Alex Deucher wrote:
> On Thu, Aug 15, 2013 at 11:48 AM, Alex Deucher wrote:
>> The vrefresh field of the mode is 0 for most modes
>> fetched from the EDID (e.g., established timings).
>> When dealing with monitors that have a bogus preferred
>> mode, we may not always select the mode we want because
>> we compare the target refresh to the mode's vrefresh which
>> is 0 in a lot of cases.
>>
>> Signed-off-by: Alex Deucher
>
> Ping? Any objections?
Anyone? Without this quirking doesn't work unless the quirked mode
happens to have the vrefesh field filled in which most modes don't.
Alex
>
> Alex
>
>> ---
>> drivers/gpu/drm/drm_edid.c | 11 ---
>> 1 file changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 58b4882..c3095e0 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -1278,7 +1278,7 @@ static u32 edid_get_quirks(struct edid *edid)
>> }
>>
>> #define MODE_SIZE(m) ((m)->hdisplay * (m)->vdisplay)
>> -#define MODE_REFRESH_DIFF(m,r) (abs((m)->vrefresh - target_refresh))
>> +#define MODE_REFRESH_DIFF(c,t) (abs((c) - (t)))
>>
>> /**
>> * edid_fixup_preferred - set preferred modes based on quirk list
>> @@ -1293,6 +1293,7 @@ static void edid_fixup_preferred(struct drm_connector
>> *connector,
>> {
>> struct drm_display_mode *t, *cur_mode, *preferred_mode;
>> int target_refresh = 0;
>> + int cur_vrefresh, preferred_vrefresh;
>>
>> if (list_empty(&connector->probed_modes))
>> return;
>> @@ -1315,10 +1316,14 @@ static void edid_fixup_preferred(struct
>> drm_connector *connector,
>> if (MODE_SIZE(cur_mode) > MODE_SIZE(preferred_mode))
>> preferred_mode = cur_mode;
>>
>> + cur_vrefresh = cur_mode->vrefresh ?
>> + cur_mode->vrefresh : drm_mode_vrefresh(cur_mode);
>> + preferred_vrefresh = preferred_mode->vrefresh ?
>> + preferred_mode->vrefresh :
>> drm_mode_vrefresh(preferred_mode);
>> /* At a given size, try to get closest to target refresh */
>> if ((MODE_SIZE(cur_mode) == MODE_SIZE(preferred_mode)) &&
>> - MODE_REFRESH_DIFF(cur_mode, target_refresh) <
>> - MODE_REFRESH_DIFF(preferred_mode, target_refresh)) {
>> + MODE_REFRESH_DIFF(cur_vrefresh, target_refresh) <
>> + MODE_REFRESH_DIFF(preferred_vrefresh, target_refresh)) {
>> preferred_mode = cur_mode;
>> }
>> }
>> --
>> 1.8.3.1
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70088] Glamor on r600g crashes Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=70088 --- Comment #12 from Krzysztof A. Sobiecki --- (In reply to comment #11) > Created attachment 87597 [details] [review] > patch > > This is an improved version of the patch, please test. Glamor acceleration with mesa + this patch works fine, will try to run piglit. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/edid: Fix the 1792x1344-75 EST III mode
On Mon, Oct 14, 2013 at 9:44 AM, wrote:
> From: Ville Syrjälä
>
> The correct refresh rate for this mode is 75, not 85.
>
> Signed-off-by: Ville Syrjälä
For the series:
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/drm_edid.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 9e81609..98d05f8 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -560,7 +560,7 @@ static const struct minimode est3_modes[] = {
> { 1600, 1200, 75, 0 },
> { 1600, 1200, 85, 0 },
> { 1792, 1344, 60, 0 },
> - { 1792, 1344, 85, 0 },
> + { 1792, 1344, 75, 0 },
> { 1856, 1392, 60, 0 },
> { 1856, 1392, 75, 0 },
> { 1920, 1200, 60, 1 },
> --
> 1.8.1.5
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 --- Comment #37 from Alexandre Demers --- (In reply to comment #36) > (In reply to comment #30) > > Is there any performance regression? If there isn't, I'm okay with the > > revert. > > I've run with the original commit 7948ed (+ little workaround) and with it > remove (both using latest git as of yesterday). I do see a performance > difference. > > I have the following result with the original commit (+ workaround): > Nexuiz -> 58.59 > OpenArea -> 59.47 > World of Padman -> 59.70 > Urban Terror -> 38.03 > Warsow -> 157.43 > > Once removed: > Nexuiz -> 58.47 > OpenArea -> 59.20 > World of Padman -> 59.63 > Urban Terror -> 37.07 > Warsow -> 141.55 > > Now, I should run it again and be sure I'm not enabling vsync here and > there. Warsow seems to be the one showing the greatest difference since it > was not hitting the refresh limit. I ran it again with vsync disabled and, while the scores went up, results are pretty close from one to another. This time, Warsow scored a bit lower with 7948ed than without it. So, it as no real impact on performances from what I can see. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Old: i810 reclaim buffers deadlock
On Mon, Oct 14, 2013 at 6:41 PM, Paul Rogers wrote: > On Mon, Oct 14, 2013, at 12:22 AM, Daniel Vetter wrote: >> On Sun, Oct 13, 2013 at 8:50 PM, Paul Rogers >> wrote: >> > Arguments: i815, kernel 2.6.34.14, XOrg-7.2, driver xf86-video-i810- >> > 1.6.5/1.7.4 >> >> I've "fixed" this in >> >> commit 87499ffdcb1c70f66988cd8febc4ead0ba2f9118 which is in v3.3 >> and later. > > Ahh, that clarifies things. Thank you for responding. > > Google turned up your patches. I have them here. But when I compared > them to my 2.6.34 kernel driver, there were too many discrepancies to > apply. But I couldn't work out when they applied. For now I'll just > have to ignore the log messages (or maybe comment them out) and rely on > the workaround. I fear upgrading the kernel from this point will break > the X-7.2 drivers, dragging in a whole chain of dependencies. Not now. > Maybe on my next upgrade go 'round. > > Thanks again! Knowing it's a problem up to 3.3 tells me what I > can do now. I'm running my i830M on latest kernels (well 3.10 or so) and things still work. Generally the kernel will keep the ABI stable for essentially forever, so upgrading should work without upgrading any piece in userspace at all. Worst case you need to downgrade to the old kernel again ;-) Also, please don't drop mailing lists when replying. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Panel Driver repository
By the same token, I'm also interested in finding a repository the latest DRI Panel Driver code. As I understand it, the DRI Panel Driver implements: A generic CRTC driver along with a few implementations of that Driver for different LCD panels. A method for those drivers to inform a central registry that they are available. A modification to an existing DRI driver so that it can check the repository for available panels and link to the appropriate panel, while all the GPU specific code, framebuffer code, etc for the existing DRI driver is used for applications to draw to the screen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63011] radeon: horizontal stripes when updating screen
https://bugzilla.kernel.org/show_bug.cgi?id=63011 --- Comment #3 from Mikko Rapeli --- Oh, forgot to mention that the problem shows up via docking station DVI port and external HP/Compaq LA2306x display. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63011] radeon: horizontal stripes when updating screen
https://bugzilla.kernel.org/show_bug.cgi?id=63011 --- Comment #2 from Mikko Rapeli --- No, userspace has not been updated. Problem is easy to reproduce and kernel is causing it. Bisect is incomplete but maybe this has some information to you: $ git bisect log git bisect start # bad: [ad81f0545ef01ea651886dddac4bef6cec930092] Linux 3.11-rc1 git bisect bad ad81f0545ef01ea651886dddac4bef6cec930092 # good: [8bb495e3f02401ee6f76d1b1d77f3ac9f079e376] Linux 3.10 git bisect good 8bb495e3f02401ee6f76d1b1d77f3ac9f079e376 # good: [1286da8bc009cb2aee7f285e94623fc974c0c983] Merge tag 'sound-3.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect good 1286da8bc009cb2aee7f285e94623fc974c0c983 # bad: [1b375dc30710180c4b88cc59caba6e3481ec5c8b] mutex: Move ww_mutex definitions to ww_mutex.h git bisect bad 1b375dc30710180c4b88cc59caba6e3481ec5c8b # good: [899dd388853071f5c8848545209d4e2c5d95b1d9] Merge tag 'for-linus-3.11-merge-window-part-1' of git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs git bisect good 899dd388853071f5c8848545209d4e2c5d95b1d9 -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
SimpleFB drivers repository?
Is there a repository for the SimpleFB drivers[the DRI driver and the plain framebuffer driver]? I'd like to play around with it for a project - I discovered it via a google search which pointed me to some archived e-mails on this list - but those e-mails just contained the patches and I'd rather just pull the latest repository then try to locate and consolidate all the patches. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70439] Mobility 4570: System freezes after ~5s of enabling audio via xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=70439 --- Comment #10 from Alex Deucher --- (In reply to comment #6) > (In reply to comment #2) > > Did you started audio before enabling it with "xrandr --output HDMI-0 --set > > audio auto" ? Had you started audio playback in the application before enabling it with xrandr? If so, do you still get the hang if you enable audio with xrandr first, and then start playback in the application? > > radeon.audio=1 seems to have no effect! > radeon.audio=1 is the default now. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64600] r600g pyrit OpenCL issue on HD6850
https://bugs.freedesktop.org/show_bug.cgi?id=64600 --- Comment #16 from Peter Wu --- Created attachment 87609 --> https://bugs.freedesktop.org/attachment.cgi?id=87609&action=edit R600_DEBUG=cs cl-program-tester struct-copy.cl The parameter tests passes when the struct contains one member, but the struct assignment still fails. Attached is the shader debug output for the original test case. LLVM: r600-private-mem-fixes rebased on master (01436ba3066b99547c1138edf5c36ef2ad467e71, SVN rev 192587) Mesa: git snb-magic-18531-ge6c2afa -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63011] radeon: horizontal stripes when updating screen
https://bugzilla.kernel.org/show_bug.cgi?id=63011 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher --- Did you also update any userspace graphics components like mesa or xf86-video-ati? If so, the problem may be in one of those components. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 64600] r600g pyrit OpenCL issue on HD6850
https://bugs.freedesktop.org/show_bug.cgi?id=64600 --- Comment #15 from Peter Wu --- Created attachment 87607 --> https://bugs.freedesktop.org/attachment.cgi?id=87607&action=edit Piglit: test copying a struct (with at least three fields) This is a smaller test case that highlights one specific issue: copying structures (consisting of at least three integers) fails. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/23] drm/exynos: Split manager/display/subdrv
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> index c417c90..ba63c72 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
> @@ -26,24 +26,23 @@
> * exynos specific encoder structure.
> *
> * @drm_encoder: encoder object.
> - * @manager: specific encoder has its own manager to control a hardware
> - * appropriately and we can access a hardware drawing on this manager.
> + * @display: the display structure that maps to this encoder
> */
> struct exynos_drm_encoder {
> struct drm_crtc *old_crtc;
> struct drm_encoder drm_encoder;
> - struct exynos_drm_manager *manager;
> + struct exynos_drm_display *display;
> };
>
> static void exynos_drm_encoder_dpms(struct drm_encoder *encoder, int mode)
> {
> - struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
> - struct exynos_drm_display_ops *display_ops = manager->display_ops;
> + struct exynos_drm_encoder *exynos_encoder =
> to_exynos_encoder(encoder);
> + struct exynos_drm_display *display = exynos_encoder->display;
>
> DRM_DEBUG_KMS("encoder dpms: %d\n", mode);
>
> - if (display_ops && display_ops->dpms)
> - display_ops->dpms(manager->ctx, mode);
> + if (display->ops->dpms)
> + display->ops->dpms(display->ctx, mode);
It's good to remove apply callback. However, it seems that this patch
has a problem that dma channel of fimd isn't enabled after dpms goes
from off to on. So can you implement win_enable callback of fimd, and
add it to fimd_win_resume function? We should have implemented
win_enable callback.
> }
>
> static bool
> @@ -52,15 +51,17 @@ exynos_drm_encoder_mode_fixup(struct drm_encoder *encoder,
>struct drm_display_mode *adjusted_mode)
> {
> struct drm_device *dev = encoder->dev;
> + struct exynos_drm_encoder *exynos_encoder =
> to_exynos_encoder(encoder);
> + struct exynos_drm_display *display = exynos_encoder->display;
> struct drm_connector *connector;
> - struct exynos_drm_manager *manager = exynos_drm_get_manager(encoder);
> - struct exynos_drm_manager_ops *manager_ops = manager->ops;
>
> list_for_each_entry(connector, &dev->mode_config.connector_list,
> head) {
> - if (connector->encoder == encoder)
> - if (manager_ops && manager_ops->mode_fixup)
> - manager_ops->mode_fixup(manager->ctx,
> connector,
> - mode, adjusted_mode);
> + if (connector->encoder != encoder)
> + continue;
> +
> + if (display->ops->mode_fixup)
> + display->ops->mode_fixup(display->ctx, connector,
> mode,
> + adjusted_mode);
> }
>
> return true;
> @@ -102,8 +103,7 @@ static void exynos_drm_encoder_mode_set(struct
> drm_encoder *encoder,
> {
> struct drm_device *dev = encoder->dev;
> struct drm_connector *connector;
> - struct exynos_drm_manager *manager;
> - struct exynos_drm_manager_ops *manager_ops;
> + struct exynos_drm_display *display;
>
> list_for_each_entry(connector, &dev->mode_config.connector_list,
> head) {
> if (connector->encoder == encoder) {
> @@ -123,11 +123,10 @@ static void exynos_drm_encoder_mode_set(struct
> drm_encoder *encoder,
> encoder->crtc);
> }
>
> - manager = exynos_drm_get_manager(encoder);
> - manager_ops = manager->ops;
> + display = exynos_encoder->display;
>
> - if (manager_ops && manager_ops->mode_set)
> - manager_ops->mode_set(manager->ctx,
> + if (display->ops->mode_set)
> + display->ops->mode_set(display->ctx,
> adjusted_mode);
>
> exynos_encoder->old_crtc = encoder->crtc;
> @@ -143,39 +142,15 @@ static void exynos_drm_encoder_prepare(struct
> drm_encoder *encoder)
> static void exynos_drm_encoder_commit(struct drm_encoder *encoder)
> {
> struct exynos_drm_encoder *exynos_encoder =
> to_exynos_encoder(encoder);
> - struct exynos_drm_manager *manager = exynos_encoder->manager;
> - struct exynos_drm_manager_ops *manager_ops = manager->ops;
> -
> - if (manager_ops && manager_ops->commit)
> - manager_ops->commit(manager->ctx);
> -}
> + struct exynos_drm_display *display = exynos_encoder->display;
>
> -void exynos_drm_encoder_complete_scanout(struct drm_framebuffer *fb)
> -{
> - struct exynos_drm_
Re: [PATCH 9/9] drm/i915: Add rotation property for sprites
On Mon, 2013-10-14 at 17:39 +0300, Ville Syrjälä wrote:
> On Mon, Oct 14, 2013 at 04:59:13PM +0300, Imre Deak wrote:
> > On Mon, 2013-09-30 at 17:44 +0300, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä
> > >
> > > Sprite planes support 180 degree rotation. The lower layers are now in
> > > place, so hook in the standard rotation property to expose the feature
> > > to the users.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > drivers/gpu/drm/i915/intel_sprite.c | 42
> > > -
> > > 2 files changed, 42 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 08e96a8..48d4d5f 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1356,6 +1356,7 @@ typedef struct drm_i915_private {
> > >
> > > struct drm_property *broadcast_rgb_property;
> > > struct drm_property *force_audio_property;
> > > + struct drm_property *rotation_property;
> > >
> > > bool hw_contexts_disabled;
> > > uint32_t hw_context_size;
> > > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > > b/drivers/gpu/drm/i915/intel_sprite.c
> > > index 028a979..49f8238 100644
> > > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > > @@ -1033,6 +1033,30 @@ out_unlock:
> > > return ret;
> > > }
> > >
> > > +static int intel_plane_set_property(struct drm_plane *plane,
> > > + struct drm_property *prop,
> > > + uint64_t val)
> > > +{
> > > + struct drm_i915_private *dev_priv = plane->dev->dev_private;
> > > + struct intel_plane *intel_plane = to_intel_plane(plane);
> > > + uint64_t old_val;
> > > + int ret = -ENOENT;
> > > +
> > > + if (prop == dev_priv->rotation_property) {
> > > + /* exactly one rotation angle please */
> > > + if (hweight32(val & 0xf) != 1)
> > > + return -EINVAL;
> > > +
> > > + old_val = intel_plane->rotation;
> > > + intel_plane->rotation = val;
> > > + ret = intel_plane_restore(plane);
> > > + if (ret)
> > > + intel_plane->rotation = old_val;
> > > + }
> > > +
> > > + return ret;
> > > +}
> > > +
> > > int intel_plane_restore(struct drm_plane *plane)
> > > {
> > > struct intel_plane *intel_plane = to_intel_plane(plane);
> > > @@ -1059,6 +1083,7 @@ static const struct drm_plane_funcs
> > > intel_plane_funcs = {
> > > .update_plane = intel_update_plane,
> > > .disable_plane = intel_disable_plane,
> > > .destroy = intel_destroy_plane,
> > > + .set_property = intel_plane_set_property,
> > > };
> > >
> > > static uint32_t ilk_plane_formats[] = {
> > > @@ -1095,6 +1120,7 @@ static uint32_t vlv_plane_formats[] = {
> > > int
> > > intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
> > > {
> > > + struct drm_i915_private *dev_priv = dev->dev_private;
> > > struct intel_plane *intel_plane;
> > > unsigned long possible_crtcs;
> > > const uint32_t *plane_formats;
> > > @@ -1168,8 +1194,22 @@ intel_plane_init(struct drm_device *dev, enum pipe
> > > pipe, int plane)
> > >&intel_plane_funcs,
> > >plane_formats, num_plane_formats,
> > >false);
> > > - if (ret)
> > > + if (ret) {
> > > kfree(intel_plane);
> > > + goto out;
> > > + }
> > > +
> > > + if (!dev_priv->rotation_property)
> > > + dev_priv->rotation_property =
> > > + drm_mode_create_rotation_property(dev,
> > > + BIT(DRM_ROTATE_0) |
> > > + BIT(DRM_ROTATE_180));
> > > +
> > > + if (dev_priv->rotation_property)
> > > + drm_object_attach_property(&intel_plane->base.base,
> > > +dev_priv->rotation_property,
> > > +intel_plane->rotation);
> >
> > drm_mode_create_rotation_property() can fail silently, I think we should
> > handle it.
>
> I figured I'd just move it to intel_modeset_init() but turns out we
> don't really handle errors there either. Frankly this looks like
> another rathole. Seeing as we already ignore property creation errors
> in other places (in a way that could oops even), I'm just going to
> run away before the urge to fix it all takes over.
Ok, since properties are already unreliable in this sense, I'm fine with
leaving this as-is for now. The series looks ok, so:
Reviewed-by: Imre Deak
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/23] drm/exynos: Pass context in manager ops instead of dev
2013/10/14 Sean Paul :
> On Mon, Oct 14, 2013 at 8:42 AM, Inki Dae wrote:
>> Hi, Sean.
>>
>>
>> It's a great patch set.:) That's exactly what we want. So I'd like to merge
>> all patch set to exynos-drm-next if there is no design issue about next
>> week. And then we can add additional minor patches from others.
>>
>> Before that, can you re-send all patch set like below?
>> 1. Do not rebase them at top of lvds-bridge patch set.
>> 2. Change all patch set for callbacks to be called
>> _with_device_object instead of ctx.
>>
>> The below is my comments.
>>
>> Thanks for your contributions,
>> Inki Dae
>>
>>> -Original Message-
>>> From: Sean Paul [mailto:seanp...@chromium.org]
>>> Sent: Friday, October 11, 2013 9:30 AM
>>> To: dri-devel@lists.freedesktop.org; inki@samsung.com
>>> Cc: airl...@linux.ie; tomasz.f...@gmail.com; marc...@chromium.org; Sean
>>> Paul
>>> Subject: [PATCH 06/23] drm/exynos: Pass context in manager ops instead of
>>> dev
>>>
>>> This patch changes the manager ops callbacks from accepting the subdrv
>>> device pointer to taking a context pointer. This will allow us to move
>>> closer to decoupling manager/display from subdrv, and subsequently
>>> decoupling the crtc/plane from the encoder.
>>>
>>> Signed-off-by: Sean Paul
>>> ---
>>> drivers/gpu/drm/exynos/exynos_drm_connector.c | 2 +-
>>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 33 ++--
>>> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 24 -
>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 71
>> +--
>>> --
>>> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 75
>> +++
>>>
>>> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 49 -
>>> 6 files changed, 130 insertions(+), 124 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
>>> index e082efb..b70b123 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
>>> @@ -198,7 +198,7 @@ static int exynos_drm_connector_fill_modes(struct
>>> drm_connector *connector,
>>>* resolution then get max width and height from that driver.
>>>*/
>>> if (ops && ops->get_max_resol)
>>> - ops->get_max_resol(manager->dev, &width, &height);
>>> + ops->get_max_resol(manager->ctx, &width, &height);
>>>
>>> return drm_helper_probe_single_connector_modes(connector, width,
>>> height);
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>> index 09bfe60..0bd444f 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>>> @@ -162,26 +162,23 @@ struct exynos_drm_display_ops {
>>> * @win_disable: disable hardware specific overlay.
>>> */
>>> struct exynos_drm_manager_ops {
>>> - int (*initialize)(struct device *subdrv_dev,
>>> - struct drm_device *drm_dev);
>>> - void (*dpms)(struct device *subdrv_dev, int mode);
>>> - void (*apply)(struct device *subdrv_dev);
>>> - void (*mode_fixup)(struct device *subdrv_dev,
>>> - struct drm_connector *connector,
>>> + int (*initialize)(void *ctx, struct drm_device *drm_dev);
>>> + void (*dpms)(void *ctx, int mode);
>>> + void (*apply)(void *ctx);
>>> + void (*mode_fixup)(void *ctx, struct drm_connector *connector,
>>> const struct drm_display_mode *mode,
>>> struct drm_display_mode *adjusted_mode);
>>> - void (*mode_set)(struct device *subdrv_dev, void *mode);
>>> - void (*get_max_resol)(struct device *subdrv_dev, unsigned int
>>> *width,
>>> + void (*mode_set)(void *ctx, void *mode);
>>> + void (*get_max_resol)(void *ctx, unsigned int *width,
>>> unsigned int *height);
>>> - void (*commit)(struct device *subdrv_dev);
>>> - int (*enable_vblank)(struct device *subdrv_dev);
>>> - void (*disable_vblank)(struct device *subdrv_dev);
>>> - void (*wait_for_vblank)(struct device *subdrv_dev);
>>> - void (*win_mode_set)(struct device *subdrv_dev,
>>> - struct exynos_drm_overlay *overlay);
>>> - void (*win_commit)(struct device *subdrv_dev, int zpos);
>>> - void (*win_enable)(struct device *subdrv_dev, int zpos);
>>> - void (*win_disable)(struct device *subdrv_dev, int zpos);
>>> + void (*commit)(void *ctx);
>>> + int (*enable_vblank)(void *ctx);
>>> + void (*disable_vblank)(void *ctx);
>>> + void (*wait_for_vblank)(void *ctx);
>>> + void (*win_mode_set)(void *ctx, struct exynos_drm_overlay *overlay);
>>> + void (*win_commit)(void *ctx, int zpos);
>>> + void (*win_enable)(void *ctx, int zpos);
>>> + void (*win_disable)(void *ctx, int zpos);
>>> }
linux-next: manual merge of the drm tree
Today's linux-next merge of the drm tree got conflicts in drivers/gpu/drm/i915/intel_drv.h caused by commits e1264eb (Revert "drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is done"), 20ddf66 (drm/i915: Make intel_crtc_active() available outside intel_pm.c), 18442d0 (drm/i915: Fix port_clock and adjusted_mode.clock readout all over), 6878da0 (drm/i915: Add intel_dotclock_calculate()) and eb14cb7 (drm/i915: Add state readout and checking for has_dp_encoder and dp_m_n). I fixed them up (see below). Please verify that the resolution looks good. Thanks, Thierry --- diff --cc drivers/gpu/drm/i915/intel_drv.h index 9b7b68f,287bbef..39bfdb3 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@@ -793,5 -817,14 +817,13 @@@ extern void hsw_pc8_disable_interrupts( extern void hsw_pc8_restore_interrupts(struct drm_device *dev); extern void intel_aux_display_runtime_get(struct drm_i915_private *dev_priv); extern void intel_aux_display_runtime_put(struct drm_i915_private *dev_priv); + extern void intel_dp_get_m_n(struct intel_crtc *crtc, +struct intel_crtc_config *pipe_config); + extern int intel_dotclock_calculate(int link_freq, + const struct intel_link_m_n *m_n); + extern void ironlake_check_encoder_dotclock(const struct intel_crtc_config *pipe_config, + int dotclock); + + extern bool intel_crtc_active(struct drm_crtc *crtc); -extern void i915_disable_vga_mem(struct drm_device *dev); #endif /* __INTEL_DRV_H__ */ ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: manual merge of the drm-intel tree
Today's linux-next merge of the drm-intel tree got conflicts in:
drivers/gpu/drm/i915/i915_dma.c
drivers/gpu/drm/i915/intel_dp.c
drivers/gpu/drm/i915/intel_drv.h
caused by commits e1264eb (Revert "drm/i915: Delay disabling of VGA memory
until vgacon->fbcon handoff is done") and ce35255 (drm/i915: Fix unclaimed
register access due to delayed VGA memory disable).
I fixed them up (see below). Please verify that the resolution looks good.
Thanks,
Thierry
---
diff --cc drivers/gpu/drm/i915/i915_dma.c
index 24640dc,42cddc1..f240150
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@@ -1350,6 -1358,13 +1355,8 @@@ static int i915_load_modeset_init(struc
*/
intel_fbdev_initial_config(dev);
- /*
- * Must do this after fbcon init so that
- * vgacon_save_screen() works during the handover.
- */
- i915_disable_vga_mem(dev);
+ intel_display_power_put(dev, POWER_DOMAIN_VGA);
+
/* Only enable hotplug handling once the fbdev is fully set up. */
dev_priv->enable_hotplug_processing = true;
diff --cc drivers/gpu/drm/i915/intel_display.c
index 1fdf49c,4a8a2e4..fbd028e
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@@ -10237,8 -10388,37 +10384,10 @@@ static void i915_disable_vga(struct drm
POSTING_READ(vga_reg);
}
-static void i915_enable_vga_mem(struct drm_device *dev)
-{
- /* Enable VGA memory on Intel HD */
- if (HAS_PCH_SPLIT(dev)) {
- vga_get_uninterruptible(dev->pdev, VGA_RSRC_LEGACY_IO);
- outb(inb(VGA_MSR_READ) | VGA_MSR_MEM_EN, VGA_MSR_WRITE);
- vga_set_legacy_decoding(dev->pdev, VGA_RSRC_LEGACY_IO |
- VGA_RSRC_LEGACY_MEM |
- VGA_RSRC_NORMAL_IO |
- VGA_RSRC_NORMAL_MEM);
- vga_put(dev->pdev, VGA_RSRC_LEGACY_IO);
- }
-}
-
-void i915_disable_vga_mem(struct drm_device *dev)
-{
- /* Disable VGA memory on Intel HD */
- if (HAS_PCH_SPLIT(dev)) {
- vga_get_uninterruptible(dev->pdev, VGA_RSRC_LEGACY_IO);
- outb(inb(VGA_MSR_READ) & ~VGA_MSR_MEM_EN, VGA_MSR_WRITE);
- vga_set_legacy_decoding(dev->pdev, VGA_RSRC_LEGACY_IO |
- VGA_RSRC_NORMAL_IO |
- VGA_RSRC_NORMAL_MEM);
- vga_put(dev->pdev, VGA_RSRC_LEGACY_IO);
- }
-}
-
void intel_modeset_init_hw(struct drm_device *dev)
{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+
intel_prepare_ddi(dev);
intel_init_clock_gating(dev);
@@@ -10510,9 -10697,10 +10666,9 @@@ void i915_redisable_vga(struct drm_devi
(I915_READ(HSW_PWR_WELL_DRIVER) & HSW_PWR_WELL_STATE_ENABLED) == 0)
return;
- if (I915_READ(vga_reg) != VGA_DISP_DISABLE) {
+ if (!(I915_READ(vga_reg) & VGA_DISP_DISABLE)) {
DRM_DEBUG_KMS("Something enabled VGA plane, disabling it\n");
i915_disable_vga(dev);
- i915_disable_vga_mem(dev);
}
}
diff --cc drivers/gpu/drm/i915/intel_dp.c
index 98f3b64,bee09e1..c392ad2
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@@ -1532,8 -1541,8 +1541,8 @@@ static void intel_edp_psr_setup(struct
intel_edp_psr_write_vsc(intel_dp, &psr_vsc);
/* Avoid continuous PSR exit by masking memup and hpd */
- I915_WRITE(EDP_PSR_DEBUG_CTL, EDP_PSR_DEBUG_MASK_MEMUP |
+ I915_WRITE(EDP_PSR_DEBUG_CTL(dev), EDP_PSR_DEBUG_MASK_MEMUP |
- EDP_PSR_DEBUG_MASK_HPD);
+ EDP_PSR_DEBUG_MASK_HPD | EDP_PSR_DEBUG_MASK_LPSP);
intel_dp->psr_setup_done = true;
}
diff --cc drivers/gpu/drm/i915/intel_drv.h
index 39bfdb3,189257d..343f0fa
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@@ -714,116 -656,196 +656,197 @@@ void assert_fdi_rx_pll(struct drm_i915_
enum pipe pipe, bool state);
#define assert_fdi_rx_pll_enabled(d, p) assert_fdi_rx_pll(d, p, true)
#define assert_fdi_rx_pll_disabled(d, p) assert_fdi_rx_pll(d, p, false)
- extern void assert_pipe(struct drm_i915_private *dev_priv, enum pipe pipe,
- bool state);
+ void assert_pipe(struct drm_i915_private *dev_priv, enum pipe pipe, bool
state);
#define assert_pipe_enabled(d, p) assert_pipe(d, p, true)
#define assert_pipe_disabled(d, p) assert_pipe(d, p, false)
+ void intel_write_eld(struct drm_encoder *encoder,
+struct drm_display_mode *mode);
+ unsigned long intel_gen4_compute_page_offset(int *x, int *y,
+unsigned int tiling_mode,
+unsigned int bpp,
+
Re: [PATCH 9/9] drm/i915: Add rotation property for sprites
On Mon, Oct 14, 2013 at 04:59:13PM +0300, Imre Deak wrote:
> On Mon, 2013-09-30 at 17:44 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Sprite planes support 180 degree rotation. The lower layers are now in
> > place, so hook in the standard rotation property to expose the feature
> > to the users.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_sprite.c | 42
> > -
> > 2 files changed, 42 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 08e96a8..48d4d5f 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1356,6 +1356,7 @@ typedef struct drm_i915_private {
> >
> > struct drm_property *broadcast_rgb_property;
> > struct drm_property *force_audio_property;
> > + struct drm_property *rotation_property;
> >
> > bool hw_contexts_disabled;
> > uint32_t hw_context_size;
> > diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> > b/drivers/gpu/drm/i915/intel_sprite.c
> > index 028a979..49f8238 100644
> > --- a/drivers/gpu/drm/i915/intel_sprite.c
> > +++ b/drivers/gpu/drm/i915/intel_sprite.c
> > @@ -1033,6 +1033,30 @@ out_unlock:
> > return ret;
> > }
> >
> > +static int intel_plane_set_property(struct drm_plane *plane,
> > + struct drm_property *prop,
> > + uint64_t val)
> > +{
> > + struct drm_i915_private *dev_priv = plane->dev->dev_private;
> > + struct intel_plane *intel_plane = to_intel_plane(plane);
> > + uint64_t old_val;
> > + int ret = -ENOENT;
> > +
> > + if (prop == dev_priv->rotation_property) {
> > + /* exactly one rotation angle please */
> > + if (hweight32(val & 0xf) != 1)
> > + return -EINVAL;
> > +
> > + old_val = intel_plane->rotation;
> > + intel_plane->rotation = val;
> > + ret = intel_plane_restore(plane);
> > + if (ret)
> > + intel_plane->rotation = old_val;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > int intel_plane_restore(struct drm_plane *plane)
> > {
> > struct intel_plane *intel_plane = to_intel_plane(plane);
> > @@ -1059,6 +1083,7 @@ static const struct drm_plane_funcs intel_plane_funcs
> > = {
> > .update_plane = intel_update_plane,
> > .disable_plane = intel_disable_plane,
> > .destroy = intel_destroy_plane,
> > + .set_property = intel_plane_set_property,
> > };
> >
> > static uint32_t ilk_plane_formats[] = {
> > @@ -1095,6 +1120,7 @@ static uint32_t vlv_plane_formats[] = {
> > int
> > intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
> > {
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > struct intel_plane *intel_plane;
> > unsigned long possible_crtcs;
> > const uint32_t *plane_formats;
> > @@ -1168,8 +1194,22 @@ intel_plane_init(struct drm_device *dev, enum pipe
> > pipe, int plane)
> > &intel_plane_funcs,
> > plane_formats, num_plane_formats,
> > false);
> > - if (ret)
> > + if (ret) {
> > kfree(intel_plane);
> > + goto out;
> > + }
> > +
> > + if (!dev_priv->rotation_property)
> > + dev_priv->rotation_property =
> > + drm_mode_create_rotation_property(dev,
> > + BIT(DRM_ROTATE_0) |
> > + BIT(DRM_ROTATE_180));
> > +
> > + if (dev_priv->rotation_property)
> > + drm_object_attach_property(&intel_plane->base.base,
> > + dev_priv->rotation_property,
> > + intel_plane->rotation);
>
> drm_mode_create_rotation_property() can fail silently, I think we should
> handle it.
I figured I'd just move it to intel_modeset_init() but turns out we
don't really handle errors there either. Frankly this looks like
another rathole. Seeing as we already ignore property creation errors
in other places (in a way that could oops even), I'm just going to
run away before the urge to fix it all takes over.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/23] drm/exynos: Pass context in manager ops instead of dev
On Mon, Oct 14, 2013 at 8:42 AM, Inki Dae wrote:
> Hi, Sean.
>
>
> It's a great patch set.:) That's exactly what we want. So I'd like to merge
> all patch set to exynos-drm-next if there is no design issue about next
> week. And then we can add additional minor patches from others.
>
> Before that, can you re-send all patch set like below?
> 1. Do not rebase them at top of lvds-bridge patch set.
> 2. Change all patch set for callbacks to be called
> _with_device_object instead of ctx.
>
> The below is my comments.
>
> Thanks for your contributions,
> Inki Dae
>
>> -Original Message-
>> From: Sean Paul [mailto:seanp...@chromium.org]
>> Sent: Friday, October 11, 2013 9:30 AM
>> To: dri-devel@lists.freedesktop.org; inki@samsung.com
>> Cc: airl...@linux.ie; tomasz.f...@gmail.com; marc...@chromium.org; Sean
>> Paul
>> Subject: [PATCH 06/23] drm/exynos: Pass context in manager ops instead of
>> dev
>>
>> This patch changes the manager ops callbacks from accepting the subdrv
>> device pointer to taking a context pointer. This will allow us to move
>> closer to decoupling manager/display from subdrv, and subsequently
>> decoupling the crtc/plane from the encoder.
>>
>> Signed-off-by: Sean Paul
>> ---
>> drivers/gpu/drm/exynos/exynos_drm_connector.c | 2 +-
>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 33 ++--
>> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 24 -
>> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 71
> +--
>> --
>> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 75
> +++
>>
>> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 49 -
>> 6 files changed, 130 insertions(+), 124 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
>> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
>> index e082efb..b70b123 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
>> @@ -198,7 +198,7 @@ static int exynos_drm_connector_fill_modes(struct
>> drm_connector *connector,
>>* resolution then get max width and height from that driver.
>>*/
>> if (ops && ops->get_max_resol)
>> - ops->get_max_resol(manager->dev, &width, &height);
>> + ops->get_max_resol(manager->ctx, &width, &height);
>>
>> return drm_helper_probe_single_connector_modes(connector, width,
>> height);
>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> index 09bfe60..0bd444f 100644
>> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
>> @@ -162,26 +162,23 @@ struct exynos_drm_display_ops {
>> * @win_disable: disable hardware specific overlay.
>> */
>> struct exynos_drm_manager_ops {
>> - int (*initialize)(struct device *subdrv_dev,
>> - struct drm_device *drm_dev);
>> - void (*dpms)(struct device *subdrv_dev, int mode);
>> - void (*apply)(struct device *subdrv_dev);
>> - void (*mode_fixup)(struct device *subdrv_dev,
>> - struct drm_connector *connector,
>> + int (*initialize)(void *ctx, struct drm_device *drm_dev);
>> + void (*dpms)(void *ctx, int mode);
>> + void (*apply)(void *ctx);
>> + void (*mode_fixup)(void *ctx, struct drm_connector *connector,
>> const struct drm_display_mode *mode,
>> struct drm_display_mode *adjusted_mode);
>> - void (*mode_set)(struct device *subdrv_dev, void *mode);
>> - void (*get_max_resol)(struct device *subdrv_dev, unsigned int
>> *width,
>> + void (*mode_set)(void *ctx, void *mode);
>> + void (*get_max_resol)(void *ctx, unsigned int *width,
>> unsigned int *height);
>> - void (*commit)(struct device *subdrv_dev);
>> - int (*enable_vblank)(struct device *subdrv_dev);
>> - void (*disable_vblank)(struct device *subdrv_dev);
>> - void (*wait_for_vblank)(struct device *subdrv_dev);
>> - void (*win_mode_set)(struct device *subdrv_dev,
>> - struct exynos_drm_overlay *overlay);
>> - void (*win_commit)(struct device *subdrv_dev, int zpos);
>> - void (*win_enable)(struct device *subdrv_dev, int zpos);
>> - void (*win_disable)(struct device *subdrv_dev, int zpos);
>> + void (*commit)(void *ctx);
>> + int (*enable_vblank)(void *ctx);
>> + void (*disable_vblank)(void *ctx);
>> + void (*wait_for_vblank)(void *ctx);
>> + void (*win_mode_set)(void *ctx, struct exynos_drm_overlay *overlay);
>> + void (*win_commit)(void *ctx, int zpos);
>> + void (*win_enable)(void *ctx, int zpos);
>> + void (*win_disable)(void *ctx, int zpos);
>> };
>>
>> /*
>> @@ -197,12 +194,14 @@ struct exynos_drm_manager_ops {
>> * these callbacks should be set by specific drivers su
Re: [PATCH v2 22/27] drm/panel: Add simple panel support
On Fri, Oct 11, 2013 at 04:33:33PM -0600, Stephen Warren wrote:
> On 10/07/2013 02:34 AM, Thierry Reding wrote:
> > Add a driver for simple panels. Such panels can have a regulator that
> > provides the supply voltage and a separate GPIO to enable the panel.
> > Optionally the panels can have a backlight associated with them so it
> > can be enabled or disabled according to the panel's power management
> > mode.
> >
> > Support is added for three panels: An AU Optronics 10.1" WSVGA, a
> > Chunghwa Picture Tubes 10.1" WXGA and a Panasonic 10.1 WUXGA TFT LCD
> > panel.
>
> > .../devicetree/bindings/panel/auo,b101aw03.txt | 7 +
> > .../bindings/panel/chunghwa,claa101wb03.txt| 7 +
> > .../bindings/panel/panasonic,vvx10f004b00.txt | 7 +
> > .../devicetree/bindings/panel/simple-panel.txt | 21 ++
>
> Since this patch defines new DT bindings, it should also be sent to the
> DT binding maintainers and DT mailing list.
I Cc'ed at least the DT mailing list. The get_maintainer.pl generated
list was pretty large, and I keep getting different feedback about
whether it's a good idea to Cc individual people or just the relevant
mailing lists. In this case I assumed that all DT binding maintainers
would be reading the DT mailing list and therefore see the patches. I
can change my habit though if you prefer to get an extra copy.
One slight inconvenience with large series like this is that a lot of
work is required to handcraft an appropriate list of people and lists
to send the patches to. Furthermore I personally like receiving whole
patch series because it gives me full context, but other people seem
to want only the patches that they need to worry about. So what I
usually do is handcraft a list of people I want to send patches to
and use it for the whole series. If that list grows too large, I'll
usually trim it down to include only lists. Having to handcraft lists
for each individual patch doesn't sound that useful to me.
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
>
> > +static int panel_simple_remove(struct platform_device *pdev)
> > +{
> > + struct panel_simple *panel = platform_get_drvdata(pdev);
> > +
> > + if (gpio_is_valid(panel->enable_gpio)) {
> > + if (panel->enable_gpio_flags & GPIO_ACTIVE_LOW)
> > + gpio_set_value(panel->enable_gpio, 1);
> > + else
> > + gpio_set_value(panel->enable_gpio, 0);
> > +
> > + gpio_free(panel->enable_gpio);
> > + }
> > +
> > + regulator_disable(panel->supply);
>
> Can you just call panel_simple_disable() to do the HW cleanup, and just
> do resource cleanup here?
Yes, I can.
Thanks,
Thierry
pgpvmUouW1xJY.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 27/27] drm/tegra: Add Tegra114 gr2d support
On Mon, Oct 14, 2013 at 08:58:34AM +0300, Terje Bergström wrote:
> On 12.10.2013 01:43, Stephen Warren wrote:
> > On 10/07/2013 02:34 AM, Thierry Reding wrote:
> >> The gr2d hardware in Tegra114 is compatible with that of Tegra20 and
> >> Tegra30. No functionaly changes are required.
> > Similarly here, if the HW is 100% backwards-compatible, there's no need
> > to add compatible values to the driver.
>
> We've used this mechanism for attaching a per-hw-version data structure
> in match table to accomodate differences in how the hardware is power
> gated, reset, booted, some per-soc performance related changes etc. It's
> also used in staging features for new chips, such as disabling power
> features when they're not working/verified yet.
>
> Upstream driver is not yet in a state where that is relevant.
>
> With this, would we still be able to do that with match table? It sounds
> like we could, because we can still (even with multiple compatible
> properties) add separate entries in match table and I guess the
> compatible properties matched in order.
Yes, as long as the device tree files includes the most specific value
in the compatible this should still be possible. So we'd have this:
gr2d@5414 {
compatible = "nvida,tegra114-gr2d", "nvidia,tegra20-gr2d";
...
};
and the driver will match on "nvidia,tegra20-gr2d" if the more specific
"nvidia,tegra114-gr2d" is not there. When the driver is updated to
support Tegra114 specific functionality, then a more specific entry can
be added to the compatible table to handle it.
Thierry
pgp4U1htrjlY5.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 9/9] drm/i915: Add rotation property for sprites
On Mon, 2013-09-30 at 17:44 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Sprite planes support 180 degree rotation. The lower layers are now in
> place, so hook in the standard rotation property to expose the feature
> to the users.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_sprite.c | 42
> -
> 2 files changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 08e96a8..48d4d5f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1356,6 +1356,7 @@ typedef struct drm_i915_private {
>
> struct drm_property *broadcast_rgb_property;
> struct drm_property *force_audio_property;
> + struct drm_property *rotation_property;
>
> bool hw_contexts_disabled;
> uint32_t hw_context_size;
> diff --git a/drivers/gpu/drm/i915/intel_sprite.c
> b/drivers/gpu/drm/i915/intel_sprite.c
> index 028a979..49f8238 100644
> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c
> @@ -1033,6 +1033,30 @@ out_unlock:
> return ret;
> }
>
> +static int intel_plane_set_property(struct drm_plane *plane,
> + struct drm_property *prop,
> + uint64_t val)
> +{
> + struct drm_i915_private *dev_priv = plane->dev->dev_private;
> + struct intel_plane *intel_plane = to_intel_plane(plane);
> + uint64_t old_val;
> + int ret = -ENOENT;
> +
> + if (prop == dev_priv->rotation_property) {
> + /* exactly one rotation angle please */
> + if (hweight32(val & 0xf) != 1)
> + return -EINVAL;
> +
> + old_val = intel_plane->rotation;
> + intel_plane->rotation = val;
> + ret = intel_plane_restore(plane);
> + if (ret)
> + intel_plane->rotation = old_val;
> + }
> +
> + return ret;
> +}
> +
> int intel_plane_restore(struct drm_plane *plane)
> {
> struct intel_plane *intel_plane = to_intel_plane(plane);
> @@ -1059,6 +1083,7 @@ static const struct drm_plane_funcs intel_plane_funcs =
> {
> .update_plane = intel_update_plane,
> .disable_plane = intel_disable_plane,
> .destroy = intel_destroy_plane,
> + .set_property = intel_plane_set_property,
> };
>
> static uint32_t ilk_plane_formats[] = {
> @@ -1095,6 +1120,7 @@ static uint32_t vlv_plane_formats[] = {
> int
> intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
> {
> + struct drm_i915_private *dev_priv = dev->dev_private;
> struct intel_plane *intel_plane;
> unsigned long possible_crtcs;
> const uint32_t *plane_formats;
> @@ -1168,8 +1194,22 @@ intel_plane_init(struct drm_device *dev, enum pipe
> pipe, int plane)
>&intel_plane_funcs,
>plane_formats, num_plane_formats,
>false);
> - if (ret)
> + if (ret) {
> kfree(intel_plane);
> + goto out;
> + }
> +
> + if (!dev_priv->rotation_property)
> + dev_priv->rotation_property =
> + drm_mode_create_rotation_property(dev,
> + BIT(DRM_ROTATE_0) |
> + BIT(DRM_ROTATE_180));
> +
> + if (dev_priv->rotation_property)
> + drm_object_attach_property(&intel_plane->base.base,
> +dev_priv->rotation_property,
> +intel_plane->rotation);
drm_mode_create_rotation_property() can fail silently, I think we should
handle it.
--Imre
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 26/27] drm/tegra: Add DSI support
On Fri, Oct 11, 2013 at 04:43:35PM -0600, Stephen Warren wrote:
> On 10/07/2013 02:34 AM, Thierry Reding wrote:
> > This commit adds support for both DSI outputs found on Tegra. Only very
> > minimal functionality is implemented, so advanced features like ganged
> > mode won't work.
> >
> > Due to the lack of other test hardware, some sections of the driver are
> > hardcoded to work with Dalmore.
>
> > diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
>
> > +static int tegra_dsi_show_regs(struct seq_file *s, void *data)
> > +{
> > + struct drm_info_node *node = s->private;
> > + struct tegra_dsi *dsi = node->info_ent->data;
> > +
> > +#define DUMP_REG(name) \
> > + seq_printf(s, "%-32s %#05x %08lx\n", #name, name, \
> > + tegra_dsi_readl(dsi, name))
> > +
> > + DUMP_REG(DSI_INCR_SYNCPT);
>
> Does it make sense to use an MMIO regmap instead? That way, you get all
> the debugfs files for free...
As far as I know, regmap doesn't give you the symbolic names for the
registers. I find that a rather useful feature because it allows to
easily compare the registers to the ones in our downstream kernels.
> > +static int tegra_dsi_probe(struct platform_device *pdev)
>
> > + dsi->clk_parent = devm_clk_get(&pdev->dev, "parent");
> > + if (IS_ERR(dsi->clk_parent))
> > + return PTR_ERR(dsi->clk_parent);
> ...
> > +static const struct of_device_id tegra_dsi_of_match[] = {
> > + { .compatible = "nvidia,tegra114-dsi", },
>
> Is this DT binding documented? The clk_get() call above in particular
> imposes the requirement that DT contain a clock with that name, which
> should be part of the binding documentation.
I've documented the requirement for both the regular "dsi" as well as
the "parent" clock in the binding documentation, which I forgot to
update in the previous series.
Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt is where
this is documented. The DSI node has a compatible property of
nvidia,tegra-dsi, which I think is a common way to write the
binding at least for Tegra.
> Hopefully the values that this driver hard-codes won't be an issue for
> the DT binding; we can simply make those values the default if
> properties are missing. I assume it's likely that such a strategy will
> work here?
They shouldn't. In fact I think it should be possible to probe them
either using mechanisms built into DSI, or by querying the attached
panel (as matched by the corresponding device tree node).
I haven't done the latter yet because I plan to investigate whether
builtin DSI functionality can be used to probe for the information.
Thierry
pgpk_AVjNEMVS.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 62721] GPU lockup: radeon 0000:01:00.0: GPU lockup CP stall for more than 10000msec...
https://bugzilla.kernel.org/show_bug.cgi?id=62721 --- Comment #7 from Egor Y. Egorov --- (In reply to Alex Deucher from comment #2) > Are you sure cb51bb7107aa040f9779be931e3bd6a7b50e0f69 is the correct commit? > That commit only affects the debugfs output. If you don't access those > debugfs files, that code in question is never called. You are right. This commit is not cause subj. Today the problem of repeated. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 6/9] drm: Add drm_rotation_simplify()
On Mon, Oct 14, 2013 at 04:46:50PM +0300, Imre Deak wrote:
> On Mon, 2013-09-30 at 17:44 +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > drm_rotation_simplify() can be used to eliminate unsupported rotation
> > flags. It will check if any unsupported flags are present, and if so
> > it will modify the rotation to an alternate form by adding 180 degrees
> > to rotation angle, and flipping the reflect x and y bits. The hope is
> > that this identity transform will eliminate the unsupported flags.
> >
> > Of course that might not result in any more supported rotation, so
> > the caller is still responsible for checking the result afterwards.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/drm_crtc.c | 30 ++
> > include/drm/drm_crtc.h | 2 ++
> > 2 files changed, 32 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 0218681..665b807 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -3976,6 +3976,36 @@ int drm_format_vert_chroma_subsampling(uint32_t
> > format)
> > EXPORT_SYMBOL(drm_format_vert_chroma_subsampling);
> >
> > /**
> > + * drm_rotation_simplify() - Try to simplify the rotation
> > + * @rotation: Rotation to be simplified
> > + * @supported_rotations: Supported rotations
> > + *
> > + * Attempt to simplify the rotation to a form that is supported.
> > + * Eg. if the hardware supports everything except DRM_REFLECT_X
> > + * one could call this function like this:
> > + *
> > + * drm_rotation_simplify(rotation, BIT(DRM_ROTATE_0) |
> > + * BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_180) |
> > + * BIT(DRM_ROTATE_270) | BIT(DRM_REFLECT_Y));
> > + *
> > + * to eliminate the DRM_ROTATE_X flag. Depending on what kind of
> ^ DRM_REFLECT_X
>
> You don't use this function in your patchset, though
> intel_plane_set_property() could use it by accepting REFLECT_X|REFLECT_Y
> too. But it does what it says, so I'm also ok if you leave it unused for
> now.
Yeah I was going back and forth whether I should accept the reflect
flags, but in the end decided against it since we can only support
a limited combination of the flags. But the function could be useful
for someone else.
>
> --Imre
>
> > + * transforms the hardware supports, this function may not
> > + * be able to produce a supported transform, so the caller should
> > + * check the result afterwards.
> > + */
> > +unsigned int drm_rotation_simplify(unsigned int rotation,
> > + unsigned int supported_rotations)
> > +{
> > + if (rotation & ~supported_rotations) {
> > + rotation ^= BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y);
> > + rotation = (rotation & ~0xf) | BIT((ffs(rotation & 0xf) + 1) %
> > 4);
> > + }
> > +
> > + return rotation;
> > +}
> > +EXPORT_SYMBOL(drm_rotation_simplify);
> > +
> > +/**
> > * drm_mode_config_init - initialize DRM mode_configuration structure
> > * @dev: DRM device
> > *
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index d25ba84..b97b367 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -1154,5 +1154,7 @@ extern int
> > drm_format_vert_chroma_subsampling(uint32_t format);
> > extern const char *drm_get_format_name(uint32_t format);
> > extern struct drm_property *drm_mode_create_rotation_property(struct
> > drm_device *dev,
> > unsigned int
> > supported_rotations);
> > +extern unsigned int drm_rotation_simplify(unsigned int rotation,
> > + unsigned int supported_rotations);
> >
> > #endif /* __DRM_CRTC_H__ */
>
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 6/9] drm: Add drm_rotation_simplify()
On Mon, 2013-09-30 at 17:44 +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> drm_rotation_simplify() can be used to eliminate unsupported rotation
> flags. It will check if any unsupported flags are present, and if so
> it will modify the rotation to an alternate form by adding 180 degrees
> to rotation angle, and flipping the reflect x and y bits. The hope is
> that this identity transform will eliminate the unsupported flags.
>
> Of course that might not result in any more supported rotation, so
> the caller is still responsible for checking the result afterwards.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_crtc.c | 30 ++
> include/drm/drm_crtc.h | 2 ++
> 2 files changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 0218681..665b807 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -3976,6 +3976,36 @@ int drm_format_vert_chroma_subsampling(uint32_t format)
> EXPORT_SYMBOL(drm_format_vert_chroma_subsampling);
>
> /**
> + * drm_rotation_simplify() - Try to simplify the rotation
> + * @rotation: Rotation to be simplified
> + * @supported_rotations: Supported rotations
> + *
> + * Attempt to simplify the rotation to a form that is supported.
> + * Eg. if the hardware supports everything except DRM_REFLECT_X
> + * one could call this function like this:
> + *
> + * drm_rotation_simplify(rotation, BIT(DRM_ROTATE_0) |
> + * BIT(DRM_ROTATE_90) | BIT(DRM_ROTATE_180) |
> + * BIT(DRM_ROTATE_270) | BIT(DRM_REFLECT_Y));
> + *
> + * to eliminate the DRM_ROTATE_X flag. Depending on what kind of
^ DRM_REFLECT_X
You don't use this function in your patchset, though
intel_plane_set_property() could use it by accepting REFLECT_X|REFLECT_Y
too. But it does what it says, so I'm also ok if you leave it unused for
now.
--Imre
> + * transforms the hardware supports, this function may not
> + * be able to produce a supported transform, so the caller should
> + * check the result afterwards.
> + */
> +unsigned int drm_rotation_simplify(unsigned int rotation,
> +unsigned int supported_rotations)
> +{
> + if (rotation & ~supported_rotations) {
> + rotation ^= BIT(DRM_REFLECT_X) | BIT(DRM_REFLECT_Y);
> + rotation = (rotation & ~0xf) | BIT((ffs(rotation & 0xf) + 1) %
> 4);
> + }
> +
> + return rotation;
> +}
> +EXPORT_SYMBOL(drm_rotation_simplify);
> +
> +/**
> * drm_mode_config_init - initialize DRM mode_configuration structure
> * @dev: DRM device
> *
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index d25ba84..b97b367 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -1154,5 +1154,7 @@ extern int drm_format_vert_chroma_subsampling(uint32_t
> format);
> extern const char *drm_get_format_name(uint32_t format);
> extern struct drm_property *drm_mode_create_rotation_property(struct
> drm_device *dev,
> unsigned int
> supported_rotations);
> +extern unsigned int drm_rotation_simplify(unsigned int rotation,
> + unsigned int supported_rotations);
>
> #endif /* __DRM_CRTC_H__ */
signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 25/27] gpu: host1x: Add MIPI pad calibration support
On Fri, Oct 11, 2013 at 04:37:35PM -0600, Stephen Warren wrote:
> On 10/07/2013 02:34 AM, Thierry Reding wrote:
> > This driver adds support to perform calibration of the MIPI pads for CSI
> > and DSI.
>
> > diff --git a/drivers/gpu/host1x/mipi.c b/drivers/gpu/host1x/mipi.c
>
> > +int tegra_mipi_calibrate(struct device *device)
> ...
> > + err = of_parse_phandle_with_args(device->of_node, "calibrate",
> > +"#calibrate-cells", 0, &args);
> ...
> > +static struct of_device_id tegra_mipi_of_match[] = {
> > + { .compatible = "nvidia,tegra114-mipi", },
>
> Is the DT binding for that compatible value documented anywhere? I'm not
> sure what #calibrate-cells means; it doesn't seem to be used...
I forgot to add a binding document, but I've complemented my local patch
series with one. The #calibrate-cells defines the number of cells used
for the specifier and should be 1. I suspect that we'll never get to
have more than 32 pads that can be calibrated, but perhaps at some point
data other than a bitmask of the pads will be needed.
Thierry
pgpkn4SgBVbek.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/edid: Yank a helpful comment about EST modes from xf86EdidModes.c
From: Ville Syrjälä
I got very confused when I tried to compare the EST modes with the spec.
Bring over a comment from xf86EdidModes.c that actually describes some
of history where these things came from.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1988865..76b10da 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -458,6 +458,15 @@ static const struct drm_display_mode drm_dmt_modes[] = {
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
};
+/*
+ * These more or less come from the DMT spec. The 720x400 modes are
+ * inferred from historical 80x25 practice. The 640x480@67 and 832x624@75
+ * modes are old-school Mac modes. The EDID spec says the 1152x864@75 mode
+ * should be 1152x870, again for the Mac, but instead we use the x864 DMT
+ * mode.
+ *
+ * The DMT modes have been fact-checked; the rest are mild guesses.
+ */
static const struct drm_display_mode edid_est_modes[] = {
{ DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 4, 800, 840,
968, 1056, 0, 600, 601, 605, 628, 0,
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/edid: Don't skip every eighth EST III mode
From: Ville Syrjälä
Also check the est3 modes whose presence is indicated by bit 0.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 98d05f8..1988865 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2080,7 +2080,7 @@ drm_est3_modes(struct drm_connector *connector, struct
detailed_timing *timing)
u8 *est = ((u8 *)timing) + 5;
for (i = 0; i < 6; i++) {
- for (j = 7; j > 0; j--) {
+ for (j = 7; j >= 0; j--) {
m = (i * 8) + (7 - j);
if (m >= ARRAY_SIZE(est3_modes))
break;
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/3] drm/edid: EST fixes
I was staring at the est modes a bit and noticed a few small bugs. Also the modes in our lists confused the hell out of me (esp. the 1152x870 vs 1152x864 issue) until I thought to go digging through xf86EdidModes.c where the history is actually documented. Looks like the >=0 vs >0 issue was also present in xf86EdidModes.c and it got already fixed there in 2012, but no one thought to bring the fix over to drm_edid.c :( ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/edid: Fix the 1792x1344-75 EST III mode
From: Ville Syrjälä
The correct refresh rate for this mode is 75, not 85.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 9e81609..98d05f8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -560,7 +560,7 @@ static const struct minimode est3_modes[] = {
{ 1600, 1200, 75, 0 },
{ 1600, 1200, 85, 0 },
{ 1792, 1344, 60, 0 },
- { 1792, 1344, 85, 0 },
+ { 1792, 1344, 75, 0 },
{ 1856, 1392, 60, 0 },
{ 1856, 1392, 75, 0 },
{ 1920, 1200, 60, 1 },
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70088] Glamor on r600g crashes Xserver
https://bugs.freedesktop.org/show_bug.cgi?id=70088 Vadim Girlin changed: What|Removed |Added Attachment #87148|0 |1 is obsolete|| --- Comment #11 from Vadim Girlin --- Created attachment 87597 --> https://bugs.freedesktop.org/attachment.cgi?id=87597&action=edit patch This is an improved version of the patch, please test. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/radeon: rework and fix reset detection v2
Am 14.10.2013 11:32, schrieb Christian König:
From: Christian König
Stop fiddling with jiffies, always wait for
RADEON_FENCE_JIFFIES_TIMEOUT.
Consolidate the two wait sequence implementations into just one
function.
Activate all waiters and remember if the reset was already done instead
of
trying to reset from only one thread.
v2: clear reset flag earlier to avoid timeout in IB test
Hello Christian,
even for radeon_fence.c Dan Carpenter had a question/patch on October,
6
[patch] drm/radeon: tweak a timeout condition slightly
and nobody replied.
Greetings,
Dieter
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 2 +-
drivers/gpu/drm/radeon/radeon_device.c | 8 +
drivers/gpu/drm/radeon/radeon_fence.c | 347
+++--
3 files changed, 127 insertions(+), 230 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h
b/drivers/gpu/drm/radeon/radeon.h
index a400ac1..0201c6e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -327,7 +327,6 @@ struct radeon_fence_driver {
/* sync_seq is protected by ring emission lock */
uint64_tsync_seq[RADEON_NUM_RINGS];
atomic64_t last_seq;
- unsigned long last_activity;
boolinitialized;
};
@@ -2170,6 +2169,7 @@ struct radeon_device {
boolneed_dma32;
boolaccel_working;
boolfastfb_working; /* IGP feature*/
+ boolneeds_reset;
struct radeon_surface_reg surface_regs[RADEON_GEM_MAX_SURFACES];
const struct firmware *me_fw; /* all family ME firmware */
const struct firmware *pfp_fw; /* r6/700 PFP firmware */
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 841d0e0..3f35f21 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1549,6 +1549,14 @@ int radeon_gpu_reset(struct radeon_device *rdev)
int resched;
down_write(&rdev->exclusive_lock);
+
+ if (!rdev->needs_reset) {
+ up_write(&rdev->exclusive_lock);
+ return 0;
+ }
+
+ rdev->needs_reset = false;
+
radeon_save_bios_scratch_regs(rdev);
/* block TTM */
resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev);
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index ddb8f8e..b8f68b2 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -190,10 +190,8 @@ void radeon_fence_process(struct radeon_device
*rdev, int ring)
}
} while (atomic64_xchg(&rdev->fence_drv[ring].last_seq, seq) > seq);
- if (wake) {
- rdev->fence_drv[ring].last_activity = jiffies;
+ if (wake)
wake_up_all(&rdev->fence_queue);
- }
}
/**
@@ -212,13 +210,13 @@ static void radeon_fence_destroy(struct kref
*kref)
}
/**
- * radeon_fence_seq_signaled - check if a fence sequeuce number has
signaled
+ * radeon_fence_seq_signaled - check if a fence sequence number has
signaled
*
* @rdev: radeon device pointer
* @seq: sequence number
* @ring: ring index the fence is associated with
*
- * Check if the last singled fence sequnce number is >= the requested
+ * Check if the last signaled fence sequnce number is >= the requested
* sequence number (all asics).
* Returns true if the fence has signaled (current fence value
* is >= requested value) or false if it has not (current fence
@@ -263,113 +261,131 @@ bool radeon_fence_signaled(struct radeon_fence
*fence)
}
/**
- * radeon_fence_wait_seq - wait for a specific sequence number
+ * radeon_fence_any_seq_signaled - check if any sequence number is
signaled
*
* @rdev: radeon device pointer
- * @target_seq: sequence number we want to wait for
- * @ring: ring index the fence is associated with
+ * @seq: sequence numbers
+ *
+ * Check if the last signaled fence sequnce number is >= the requested
+ * sequence number (all asics).
+ * Returns true if any has signaled (current value is >= requested
value)
+ * or false if it has not. Helper function for radeon_fence_wait_seq.
+ */
+static bool radeon_fence_any_seq_signaled(struct radeon_device *rdev,
u64 *seq)
+{
+ unsigned i;
+
+ for (i = 0; i < RADEON_NUM_RINGS; ++i) {
+ if (seq[i] && radeon_fence_seq_signaled(rdev, seq[i], i))
+ return true;
+ }
+ return false;
+}
+
+/**
+ * radeon_fence_wait_seq - wait for a specific sequence numbers
+ *
+ * @rdev: radeon device pointer
+ * @target_seq: sequence number(s) we want to wait for
* @intr: use interruptable sleep
* @lock_ring: whether the ring should be locked or not
*
- * Wait for the requested se
RE: [PATCH 06/23] drm/exynos: Pass context in manager ops instead of dev
Hi, Sean.
It's a great patch set.:) That's exactly what we want. So I'd like to merge
all patch set to exynos-drm-next if there is no design issue about next
week. And then we can add additional minor patches from others.
Before that, can you re-send all patch set like below?
1. Do not rebase them at top of lvds-bridge patch set.
2. Change all patch set for callbacks to be called
_with_device_object instead of ctx.
The below is my comments.
Thanks for your contributions,
Inki Dae
> -Original Message-
> From: Sean Paul [mailto:seanp...@chromium.org]
> Sent: Friday, October 11, 2013 9:30 AM
> To: dri-devel@lists.freedesktop.org; inki@samsung.com
> Cc: airl...@linux.ie; tomasz.f...@gmail.com; marc...@chromium.org; Sean
> Paul
> Subject: [PATCH 06/23] drm/exynos: Pass context in manager ops instead of
> dev
>
> This patch changes the manager ops callbacks from accepting the subdrv
> device pointer to taking a context pointer. This will allow us to move
> closer to decoupling manager/display from subdrv, and subsequently
> decoupling the crtc/plane from the encoder.
>
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/exynos/exynos_drm_connector.c | 2 +-
> drivers/gpu/drm/exynos/exynos_drm_drv.h | 33 ++--
> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 24 -
> drivers/gpu/drm/exynos/exynos_drm_fimd.c | 71
+--
> --
> drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 75
+++
>
> drivers/gpu/drm/exynos/exynos_drm_vidi.c | 49 -
> 6 files changed, 130 insertions(+), 124 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> index e082efb..b70b123 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_connector.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_connector.c
> @@ -198,7 +198,7 @@ static int exynos_drm_connector_fill_modes(struct
> drm_connector *connector,
>* resolution then get max width and height from that driver.
>*/
> if (ops && ops->get_max_resol)
> - ops->get_max_resol(manager->dev, &width, &height);
> + ops->get_max_resol(manager->ctx, &width, &height);
>
> return drm_helper_probe_single_connector_modes(connector, width,
> height);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> index 09bfe60..0bd444f 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> @@ -162,26 +162,23 @@ struct exynos_drm_display_ops {
> * @win_disable: disable hardware specific overlay.
> */
> struct exynos_drm_manager_ops {
> - int (*initialize)(struct device *subdrv_dev,
> - struct drm_device *drm_dev);
> - void (*dpms)(struct device *subdrv_dev, int mode);
> - void (*apply)(struct device *subdrv_dev);
> - void (*mode_fixup)(struct device *subdrv_dev,
> - struct drm_connector *connector,
> + int (*initialize)(void *ctx, struct drm_device *drm_dev);
> + void (*dpms)(void *ctx, int mode);
> + void (*apply)(void *ctx);
> + void (*mode_fixup)(void *ctx, struct drm_connector *connector,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode);
> - void (*mode_set)(struct device *subdrv_dev, void *mode);
> - void (*get_max_resol)(struct device *subdrv_dev, unsigned int
> *width,
> + void (*mode_set)(void *ctx, void *mode);
> + void (*get_max_resol)(void *ctx, unsigned int *width,
> unsigned int *height);
> - void (*commit)(struct device *subdrv_dev);
> - int (*enable_vblank)(struct device *subdrv_dev);
> - void (*disable_vblank)(struct device *subdrv_dev);
> - void (*wait_for_vblank)(struct device *subdrv_dev);
> - void (*win_mode_set)(struct device *subdrv_dev,
> - struct exynos_drm_overlay *overlay);
> - void (*win_commit)(struct device *subdrv_dev, int zpos);
> - void (*win_enable)(struct device *subdrv_dev, int zpos);
> - void (*win_disable)(struct device *subdrv_dev, int zpos);
> + void (*commit)(void *ctx);
> + int (*enable_vblank)(void *ctx);
> + void (*disable_vblank)(void *ctx);
> + void (*wait_for_vblank)(void *ctx);
> + void (*win_mode_set)(void *ctx, struct exynos_drm_overlay *overlay);
> + void (*win_commit)(void *ctx, int zpos);
> + void (*win_enable)(void *ctx, int zpos);
> + void (*win_disable)(void *ctx, int zpos);
> };
>
> /*
> @@ -197,12 +194,14 @@ struct exynos_drm_manager_ops {
> * these callbacks should be set by specific drivers such fimd
> * or hdmi driver and are used to control display devices such as
> * analog tv, digital tv and lcd panel and also get timing data for
> them.
> + * @
[PATCHv2 4/4] drm/tegra: Reserve base for gr2d
This patch modifies the gr2d to reserve a base for syncpoint.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/drm/gr2d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/host1x/drm/gr2d.c b/drivers/gpu/host1x/drm/gr2d.c
index 7efd97b..337e1ad 100644
--- a/drivers/gpu/host1x/drm/gr2d.c
+++ b/drivers/gpu/host1x/drm/gr2d.c
@@ -285,7 +285,7 @@ static int gr2d_probe(struct platform_device *pdev)
if (!gr2d->channel)
return -ENOMEM;
- *syncpts = host1x_syncpt_request(dev, 0);
+ *syncpts = host1x_syncpt_request(dev, HOST1X_SYNCPT_HAS_BASE);
if (!(*syncpts)) {
host1x_channel_free(gr2d->channel);
return -ENOMEM;
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv2 3/4] drm/tegra: Deliver syncpoint base to user space
This patch adds a separate ioctl for delivering syncpoint base number
to user space. If the syncpoint does not have an associated base, the
function returns -ENXIO.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/drm/drm.c | 25 +
include/uapi/drm/tegra_drm.h | 26 +-
2 files changed, 42 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/host1x/drm/drm.c b/drivers/gpu/host1x/drm/drm.c
index 8c61cee..c11cbf5 100644
--- a/drivers/gpu/host1x/drm/drm.c
+++ b/drivers/gpu/host1x/drm/drm.c
@@ -472,6 +472,30 @@ static int tegra_get_syncpt(struct drm_device *drm, void
*data,
return 0;
}
+static int tegra_get_syncpt_base(struct drm_device *drm, void *data,
+struct drm_file *file)
+{
+ struct drm_tegra_get_syncpt_base *args = data;
+ struct host1x_drm_file *fpriv = file->driver_priv;
+ struct host1x_drm_context *context =
+ (struct host1x_drm_context *)(uintptr_t)args->context;
+ struct host1x_syncpt_base *base;
+
+ if (!host1x_drm_file_owns_context(fpriv, context))
+ return -ENODEV;
+
+ if (args->index >= context->client->num_syncpts)
+ return -EINVAL;
+
+ base = context->client->syncpts[args->index]->base;
+ if (!base)
+ return -ENXIO;
+
+ args->base_id = base->id;
+
+ return 0;
+}
+
static int tegra_submit(struct drm_device *drm, void *data,
struct drm_file *file)
{
@@ -498,6 +522,7 @@ static const struct drm_ioctl_desc tegra_drm_ioctls[] = {
DRM_IOCTL_DEF_DRV(TEGRA_CLOSE_CHANNEL, tegra_close_channel,
DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT, tegra_get_syncpt, DRM_UNLOCKED),
DRM_IOCTL_DEF_DRV(TEGRA_SUBMIT, tegra_submit, DRM_UNLOCKED),
+ DRM_IOCTL_DEF_DRV(TEGRA_GET_SYNCPT_BASE, tegra_get_syncpt_base,
DRM_UNLOCKED),
#endif
};
diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index 73bde4e..8b8094c 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -65,6 +65,12 @@ struct drm_tegra_get_syncpt {
__u32 id;
};
+struct drm_tegra_get_syncpt_base {
+ __u64 context;
+ __u32 index;
+ __u32 base_id;
+};
+
struct drm_tegra_syncpt {
__u32 id;
__u32 incrs;
@@ -115,15 +121,16 @@ struct drm_tegra_submit {
__u32 reserved[5]; /* future expansion */
};
-#define DRM_TEGRA_GEM_CREATE 0x00
-#define DRM_TEGRA_GEM_MMAP 0x01
-#define DRM_TEGRA_SYNCPT_READ 0x02
-#define DRM_TEGRA_SYNCPT_INCR 0x03
-#define DRM_TEGRA_SYNCPT_WAIT 0x04
-#define DRM_TEGRA_OPEN_CHANNEL 0x05
-#define DRM_TEGRA_CLOSE_CHANNEL0x06
-#define DRM_TEGRA_GET_SYNCPT 0x07
-#define DRM_TEGRA_SUBMIT 0x08
+#define DRM_TEGRA_GEM_CREATE 0x00
+#define DRM_TEGRA_GEM_MMAP 0x01
+#define DRM_TEGRA_SYNCPT_READ 0x02
+#define DRM_TEGRA_SYNCPT_INCR 0x03
+#define DRM_TEGRA_SYNCPT_WAIT 0x04
+#define DRM_TEGRA_OPEN_CHANNEL 0x05
+#define DRM_TEGRA_CLOSE_CHANNEL0x06
+#define DRM_TEGRA_GET_SYNCPT 0x07
+#define DRM_TEGRA_SUBMIT 0x08
+#define DRM_TEGRA_GET_SYNCPT_BASE 0x09
#define DRM_IOCTL_TEGRA_GEM_CREATE DRM_IOWR(DRM_COMMAND_BASE +
DRM_TEGRA_GEM_CREATE, struct drm_tegra_gem_create)
#define DRM_IOCTL_TEGRA_GEM_MMAP DRM_IOWR(DRM_COMMAND_BASE +
DRM_TEGRA_GEM_MMAP, struct drm_tegra_gem_mmap)
@@ -134,5 +141,6 @@ struct drm_tegra_submit {
#define DRM_IOCTL_TEGRA_CLOSE_CHANNEL DRM_IOWR(DRM_COMMAND_BASE +
DRM_TEGRA_CLOSE_CHANNEL, struct drm_tegra_open_channel)
#define DRM_IOCTL_TEGRA_GET_SYNCPT DRM_IOWR(DRM_COMMAND_BASE +
DRM_TEGRA_GET_SYNCPT, struct drm_tegra_get_syncpt)
#define DRM_IOCTL_TEGRA_SUBMIT DRM_IOWR(DRM_COMMAND_BASE + DRM_TEGRA_SUBMIT,
struct drm_tegra_submit)
+#define DRM_IOCTL_TEGRA_GET_SYNCPT_BASE DRM_IOWR(DRM_COMMAND_BASE +
DRM_TEGRA_GET_SYNCPT_BASE, struct drm_tegra_get_syncpt_base)
#endif
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv2 2/4] gpu: host1x: Add syncpoint base support
This patch adds support for hardware syncpoint bases. This creates
a simple mechanism to stall the command FIFO until an operation is
completed.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/dev.h | 2 ++
drivers/gpu/host1x/hw/channel_hw.c | 19 +
drivers/gpu/host1x/hw/hw_host1x01_uclass.h | 6
drivers/gpu/host1x/syncpt.c| 44 --
drivers/gpu/host1x/syncpt.h| 7 +
5 files changed, 76 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/host1x/dev.h b/drivers/gpu/host1x/dev.h
index bed90a8..516ce0a 100644
--- a/drivers/gpu/host1x/dev.h
+++ b/drivers/gpu/host1x/dev.h
@@ -27,6 +27,7 @@
#include "job.h"
struct host1x_syncpt;
+struct host1x_syncpt_base;
struct host1x_channel;
struct host1x_cdma;
struct host1x_job;
@@ -102,6 +103,7 @@ struct host1x {
void __iomem *regs;
struct host1x_syncpt *syncpt;
+ struct host1x_syncpt_base *bases;
struct device *dev;
struct clk *clk;
diff --git a/drivers/gpu/host1x/hw/channel_hw.c
b/drivers/gpu/host1x/hw/channel_hw.c
index ee19962..06f44bf 100644
--- a/drivers/gpu/host1x/hw/channel_hw.c
+++ b/drivers/gpu/host1x/hw/channel_hw.c
@@ -67,6 +67,21 @@ static void submit_gathers(struct host1x_job *job)
}
}
+static inline void synchronize_syncpt_base(struct host1x_job *job)
+{
+ struct host1x_channel *ch = job->channel;
+ struct host1x *host = dev_get_drvdata(ch->dev->parent);
+ struct host1x_syncpt *sp = host->syncpt + job->syncpt_id;
+ u32 base_id = sp->base->id;
+ u32 base_val = host1x_syncpt_read_max(sp);
+
+ host1x_cdma_push(&ch->cdma,
+host1x_opcode_setclass(HOST1X_CLASS_HOST1X,
+ HOST1X_UCLASS_LOAD_SYNCPT_BASE, 1),
+HOST1X_UCLASS_LOAD_SYNCPT_BASE_BASE_INDX_F(base_id) |
+HOST1X_UCLASS_LOAD_SYNCPT_BASE_VALUE_F(base_val));
+}
+
static int channel_submit(struct host1x_job *job)
{
struct host1x_channel *ch = job->channel;
@@ -118,6 +133,10 @@ static int channel_submit(struct host1x_job *job)
host1x_syncpt_read_max(sp)));
}
+ /* Synchronize base register to allow using it for relative waiting */
+ if (sp->base)
+ synchronize_syncpt_base(job);
+
syncval = host1x_syncpt_incr_max(sp, user_syncpt_incrs);
job->syncpt_end = syncval;
diff --git a/drivers/gpu/host1x/hw/hw_host1x01_uclass.h
b/drivers/gpu/host1x/hw/hw_host1x01_uclass.h
index 42f3ce1..f755359 100644
--- a/drivers/gpu/host1x/hw/hw_host1x01_uclass.h
+++ b/drivers/gpu/host1x/hw/hw_host1x01_uclass.h
@@ -111,6 +111,12 @@ static inline u32
host1x_uclass_wait_syncpt_base_offset_f(u32 v)
}
#define HOST1X_UCLASS_WAIT_SYNCPT_BASE_OFFSET_F(v) \
host1x_uclass_wait_syncpt_base_offset_f(v)
+static inline u32 host1x_uclass_load_syncpt_base_r(void)
+{
+ return 0xb;
+}
+#define HOST1X_UCLASS_LOAD_SYNCPT_BASE \
+ host1x_uclass_load_syncpt_base_r()
static inline u32 host1x_uclass_load_syncpt_base_base_indx_f(u32 v)
{
return (v & 0xff) << 24;
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
index d376cd4..b5cb97c 100644
--- a/drivers/gpu/host1x/syncpt.c
+++ b/drivers/gpu/host1x/syncpt.c
@@ -30,6 +30,28 @@
#define SYNCPT_CHECK_PERIOD (2 * HZ)
#define MAX_STUCK_CHECK_COUNT 15
+static struct host1x_syncpt_base *host1x_base_alloc(struct host1x *host)
+{
+ struct host1x_syncpt_base *bases = host->bases;
+ unsigned int i;
+
+ for (i = 0; i < host->info->nb_bases; i++)
+ if (!bases[i].requested)
+ break;
+
+ if (i >= host->info->nb_bases)
+ return NULL;
+
+ bases[i].requested = true;
+ return &bases[i];
+}
+
+static void host1x_syncpt_base_free(struct host1x_syncpt_base *base)
+{
+ if (base)
+ base->requested = false;
+}
+
static struct host1x_syncpt *host1x_syncpt_alloc(struct host1x *host,
struct device *dev,
unsigned long flags)
@@ -44,6 +66,12 @@ static struct host1x_syncpt *host1x_syncpt_alloc(struct
host1x *host,
if (i >= host->info->nb_pts)
return NULL;
+ if (flags & HOST1X_SYNCPT_HAS_BASE) {
+ sp->base = host1x_base_alloc(host);
+ if (!sp->base)
+ return NULL;
+ }
+
name = kasprintf(GFP_KERNEL, "%02d-%s", sp->id,
dev ? dev_name(dev) : NULL);
if (!name)
@@ -304,19 +332,29 @@ int host1x_syncpt_patch_wait(struct host1x_syncpt *sp,
void *patch_addr)
int host1x_syncpt_init(struct host1x *host)
{
struct host1x_syncpt *syncpt;
+ struct host1x_syncpt_base *bases;
int i;
syncpt = devm_kzalloc(host->dev, sizeof(*syn
[PATCHv2 1/4] gpu: host1x: Add 'flags' field to syncpt request
Functions host1x_syncpt_request() and _host1x_syncpt_alloc() have
been taking a separate boolean flag ('client_managed') for indicating
if the syncpoint value should be tracked by the host1x driver.
This patch converts the field into generic 'flags' field so that
we can easily add more information while requesting a syncpoint.
Clients are adapted to use the new interface accordingly.
Signed-off-by: Arto Merilainen
---
drivers/gpu/host1x/drm/gr2d.c | 2 +-
drivers/gpu/host1x/syncpt.c | 14 +++---
drivers/gpu/host1x/syncpt.h | 3 ++-
3 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/host1x/drm/gr2d.c b/drivers/gpu/host1x/drm/gr2d.c
index 27ffcf1..7efd97b 100644
--- a/drivers/gpu/host1x/drm/gr2d.c
+++ b/drivers/gpu/host1x/drm/gr2d.c
@@ -285,7 +285,7 @@ static int gr2d_probe(struct platform_device *pdev)
if (!gr2d->channel)
return -ENOMEM;
- *syncpts = host1x_syncpt_request(dev, false);
+ *syncpts = host1x_syncpt_request(dev, 0);
if (!(*syncpts)) {
host1x_channel_free(gr2d->channel);
return -ENOMEM;
diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
index 409745b..d376cd4 100644
--- a/drivers/gpu/host1x/syncpt.c
+++ b/drivers/gpu/host1x/syncpt.c
@@ -30,9 +30,9 @@
#define SYNCPT_CHECK_PERIOD (2 * HZ)
#define MAX_STUCK_CHECK_COUNT 15
-static struct host1x_syncpt *_host1x_syncpt_alloc(struct host1x *host,
- struct device *dev,
- bool client_managed)
+static struct host1x_syncpt *host1x_syncpt_alloc(struct host1x *host,
+struct device *dev,
+unsigned long flags)
{
int i;
struct host1x_syncpt *sp = host->syncpt;
@@ -51,7 +51,7 @@ static struct host1x_syncpt *_host1x_syncpt_alloc(struct
host1x *host,
sp->dev = dev;
sp->name = name;
- sp->client_managed = client_managed;
+ sp->client_managed = !!(flags & HOST1X_SYNCPT_CLIENT_MANAGED);
return sp;
}
@@ -321,7 +321,7 @@ int host1x_syncpt_init(struct host1x *host)
host1x_syncpt_restore(host);
/* Allocate sync point to use for clearing waits for expired fences */
- host->nop_sp = _host1x_syncpt_alloc(host, NULL, false);
+ host->nop_sp = host1x_syncpt_alloc(host, NULL, 0);
if (!host->nop_sp)
return -ENOMEM;
@@ -329,10 +329,10 @@ int host1x_syncpt_init(struct host1x *host)
}
struct host1x_syncpt *host1x_syncpt_request(struct device *dev,
- bool client_managed)
+ unsigned long flags)
{
struct host1x *host = dev_get_drvdata(dev->parent);
- return _host1x_syncpt_alloc(host, dev, client_managed);
+ return host1x_syncpt_alloc(host, dev, flags);
}
void host1x_syncpt_free(struct host1x_syncpt *sp)
diff --git a/drivers/gpu/host1x/syncpt.h b/drivers/gpu/host1x/syncpt.h
index 267c0b9..1de7b58 100644
--- a/drivers/gpu/host1x/syncpt.h
+++ b/drivers/gpu/host1x/syncpt.h
@@ -153,8 +153,9 @@ int host1x_syncpt_patch_wait(struct host1x_syncpt *sp, void
*patch_addr);
u32 host1x_syncpt_id(struct host1x_syncpt *sp);
/* Allocate a sync point for a device. */
+#define HOST1X_SYNCPT_CLIENT_MANAGED (1 << 0)
struct host1x_syncpt *host1x_syncpt_request(struct device *dev,
- bool client_managed);
+ unsigned long flags);
/* Free a sync point. */
void host1x_syncpt_free(struct host1x_syncpt *sp);
--
1.8.1.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv2 0/4] gpu: host1x: Add syncpoint base support
The host1x driver uses currently syncpoints statically from host1x point of view. If we do a wait inside a job, it always has a constant value to wait. host1x supports also doing relative syncpoint waits with respect to syncpoint bases. This allows doing multiple operations inside a single submit and waiting an operation to complete before moving to next one. This set of patches adds support for syncpoint bases to host1x driver and enables the support for gr2d client. I have tested the series using the host1x test application (available at [0], function test_wait_base() in tests/tegra/host1x/tegra_host1x_test.c) on cardhu. I would appreciate help in reviewing the series and testing the patches on other boards. Changes in v2: - Reordered various code blocks to improve code consistency - Functions host1x_syncpt_alloc() and host1x_syncpt_request() take now a single bitfield argument instead of separate boolean arguments - Added a separate ioctl call for querying the base associated with some syncpoint [0] https://gitorious.org/linux-host1x/libdrm-host1x Arto Merilainen (4): gpu: host1x: Add 'flags' field to syncpt request gpu: host1x: Add syncpoint base support drm/tegra: Deliver syncpoint base to user space drm/tegra: Reserve base for gr2d drivers/gpu/host1x/dev.h | 2 ++ drivers/gpu/host1x/drm/drm.c | 25 + drivers/gpu/host1x/drm/gr2d.c | 2 +- drivers/gpu/host1x/hw/channel_hw.c | 19 ++ drivers/gpu/host1x/hw/hw_host1x01_uclass.h | 6 drivers/gpu/host1x/syncpt.c| 58 +- drivers/gpu/host1x/syncpt.h| 10 +- include/uapi/drm/tegra_drm.h | 26 +- 8 files changed, 128 insertions(+), 20 deletions(-) -- 1.8.1.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70035] GPU Lockup on AMD RS880 HD4200
https://bugs.freedesktop.org/show_bug.cgi?id=70035 Tasev changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Tasev --- Hi, Everything is working fine for more than 4 days now so i'm closing this bug. Thank's to every one for the help. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70439] Mobility 4570: System freezes after ~5s of enabling audio via xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=70439 --- Comment #9 from Mohammad AlSaleh --- It is worth noting that the (frozen) frame is still signaled and audio starts looping after the freeze. Which maybe indicate an endless loop. Also, when the freeze is not instant, audio keeps working seconds after the display is frozen. Then, it starts looping. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70439] Mobility 4570: System freezes after ~5s of enabling audio via xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=70439 --- Comment #8 from Mohammad AlSaleh --- Created attachment 87594 --> https://bugs.freedesktop.org/attachment.cgi?id=87594&action=edit dmesg (audio + no dpm) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70439] Mobility 4570: System freezes after ~5s of enabling audio via xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=70439 --- Comment #7 from Mohammad AlSaleh --- Created attachment 87593 --> https://bugs.freedesktop.org/attachment.cgi?id=87593&action=edit dmesg (audio+dpm) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70439] Mobility 4570: System freezes after ~5s of enabling audio via xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=70439 --- Comment #6 from Mohammad AlSaleh --- (In reply to comment #2) > Did you started audio before enabling it with "xrandr --output HDMI-0 --set > audio auto" ? radeon.audio=1 seems to have no effect! Passing it does not enable audio. And using xrandr later causes the same freeze. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70439] Mobility 4570: System freezes after ~5s of enabling audio via xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=70439 --- Comment #5 from Mohammad AlSaleh --- (In reply to comment #1) > Please attach your xorg log and dmesg output. If this is a regression can > you use git to bisect? I don't think I have enough free space to clone the kernel. So bisection is not easy for me unless there is a submoduled repository I'm not aware of. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70439] Mobility 4570: System freezes after ~5s of enabling audio via xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=70439 --- Comment #4 from Mohammad AlSaleh --- Created attachment 87591 --> https://bugs.freedesktop.org/attachment.cgi?id=87591&action=edit Xorg.0.log (current run with DPM) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70439] Mobility 4570: System freezes after ~5s of enabling audio via xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=70439 --- Comment #3 from Mohammad AlSaleh --- Created attachment 87590 --> https://bugs.freedesktop.org/attachment.cgi?id=87590&action=edit dmesg (current run with DPM) -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 63011] New: radeon: horizontal stripes when updating screen
https://bugzilla.kernel.org/show_bug.cgi?id=63011 Bug ID: 63011 Summary: radeon: horizontal stripes when updating screen Product: Drivers Version: 2.5 Kernel Version: 3.11.5 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: mikko.rap...@iki.fi Regression: No After updating kernel from 3.10.9 to 3.11.2 and now .5, content in non-active windows in X are showing horizontal stripes, I guess one pixel high and width of the non-active window in X, when for example scrolling down a browser page using the mouse wheel. Also the mouse pointer in X is sometimes flickering much more than before with 3.10 and older kernels. Base system: Ubuntu 12.04 LTS, Xorg 1.11.3. PC: HP EliteBook 8560p, Core i7 with Radeon graphics Radeon graphics details, lcpci -v -v: 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI Seymour [Radeon HD 6400M Series] (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device 161a Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [150 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap+ ChkEn- Kernel modules: radeon Tried to bisect this but the results were pointing to drm/i915 commits between 3.10 and 3.11rc2 so I guess I did something wrong. Will try again later. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/radeon: rework and fix reset detection v2
From: Christian König
Stop fiddling with jiffies, always wait for RADEON_FENCE_JIFFIES_TIMEOUT.
Consolidate the two wait sequence implementations into just one function.
Activate all waiters and remember if the reset was already done instead of
trying to reset from only one thread.
v2: clear reset flag earlier to avoid timeout in IB test
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h| 2 +-
drivers/gpu/drm/radeon/radeon_device.c | 8 +
drivers/gpu/drm/radeon/radeon_fence.c | 347 +++--
3 files changed, 127 insertions(+), 230 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index a400ac1..0201c6e 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -327,7 +327,6 @@ struct radeon_fence_driver {
/* sync_seq is protected by ring emission lock */
uint64_tsync_seq[RADEON_NUM_RINGS];
atomic64_t last_seq;
- unsigned long last_activity;
boolinitialized;
};
@@ -2170,6 +2169,7 @@ struct radeon_device {
boolneed_dma32;
boolaccel_working;
boolfastfb_working; /* IGP feature*/
+ boolneeds_reset;
struct radeon_surface_reg surface_regs[RADEON_GEM_MAX_SURFACES];
const struct firmware *me_fw; /* all family ME firmware */
const struct firmware *pfp_fw; /* r6/700 PFP firmware */
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 841d0e0..3f35f21 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1549,6 +1549,14 @@ int radeon_gpu_reset(struct radeon_device *rdev)
int resched;
down_write(&rdev->exclusive_lock);
+
+ if (!rdev->needs_reset) {
+ up_write(&rdev->exclusive_lock);
+ return 0;
+ }
+
+ rdev->needs_reset = false;
+
radeon_save_bios_scratch_regs(rdev);
/* block TTM */
resched = ttm_bo_lock_delayed_workqueue(&rdev->mman.bdev);
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index ddb8f8e..b8f68b2 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -190,10 +190,8 @@ void radeon_fence_process(struct radeon_device *rdev, int
ring)
}
} while (atomic64_xchg(&rdev->fence_drv[ring].last_seq, seq) > seq);
- if (wake) {
- rdev->fence_drv[ring].last_activity = jiffies;
+ if (wake)
wake_up_all(&rdev->fence_queue);
- }
}
/**
@@ -212,13 +210,13 @@ static void radeon_fence_destroy(struct kref *kref)
}
/**
- * radeon_fence_seq_signaled - check if a fence sequeuce number has signaled
+ * radeon_fence_seq_signaled - check if a fence sequence number has signaled
*
* @rdev: radeon device pointer
* @seq: sequence number
* @ring: ring index the fence is associated with
*
- * Check if the last singled fence sequnce number is >= the requested
+ * Check if the last signaled fence sequnce number is >= the requested
* sequence number (all asics).
* Returns true if the fence has signaled (current fence value
* is >= requested value) or false if it has not (current fence
@@ -263,113 +261,131 @@ bool radeon_fence_signaled(struct radeon_fence *fence)
}
/**
- * radeon_fence_wait_seq - wait for a specific sequence number
+ * radeon_fence_any_seq_signaled - check if any sequence number is signaled
*
* @rdev: radeon device pointer
- * @target_seq: sequence number we want to wait for
- * @ring: ring index the fence is associated with
+ * @seq: sequence numbers
+ *
+ * Check if the last signaled fence sequnce number is >= the requested
+ * sequence number (all asics).
+ * Returns true if any has signaled (current value is >= requested value)
+ * or false if it has not. Helper function for radeon_fence_wait_seq.
+ */
+static bool radeon_fence_any_seq_signaled(struct radeon_device *rdev, u64 *seq)
+{
+ unsigned i;
+
+ for (i = 0; i < RADEON_NUM_RINGS; ++i) {
+ if (seq[i] && radeon_fence_seq_signaled(rdev, seq[i], i))
+ return true;
+ }
+ return false;
+}
+
+/**
+ * radeon_fence_wait_seq - wait for a specific sequence numbers
+ *
+ * @rdev: radeon device pointer
+ * @target_seq: sequence number(s) we want to wait for
* @intr: use interruptable sleep
* @lock_ring: whether the ring should be locked or not
*
- * Wait for the requested sequence number to be written (all asics).
+ * Wait for the requested sequence number(s) to be written by any ring
+ * (all asics). Sequnce number array is indexed by ring id.
* @intr selects whether to use interruptable (true) or non-interruptable
*
[PATCH 1/2] drm/radeon: stop the leaks in cik_ib_test
From: Christian König
Stop leaking IB memory and scratch register space when the test fails.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/cik.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index b874ccd..8f393df 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -3182,6 +3182,7 @@ int cik_ib_test(struct radeon_device *rdev, struct
radeon_ring *ring)
r = radeon_ib_get(rdev, ring->idx, &ib, NULL, 256);
if (r) {
DRM_ERROR("radeon: failed to get ib (%d).\n", r);
+ radeon_scratch_free(rdev, scratch);
return r;
}
ib.ptr[0] = PACKET3(PACKET3_SET_UCONFIG_REG, 1);
@@ -3198,6 +3199,8 @@ int cik_ib_test(struct radeon_device *rdev, struct
radeon_ring *ring)
r = radeon_fence_wait(ib.fence, false);
if (r) {
DRM_ERROR("radeon: fence wait failed (%d).\n", r);
+ radeon_scratch_free(rdev, scratch);
+ radeon_ib_free(rdev, &ib);
return r;
}
for (i = 0; i < rdev->usec_timeout; i++) {
--
1.8.1.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: signal all fences after lockup to avoid endless waiting in GEM_WAIT
Ok, that one was easy to fix. Please apply the attached patch as well. Going to send out both for inclusion in 3.12 in a minute. Christian. Am 13.10.2013 22:16, schrieb Marek Olšák: This seems to be better. It can do about 3-5 resets correctly, then the GPU resuming fails: [ 246.882780] [drm:cik_resume] *ERROR* cik startup failed on resume and then the GPU is being reset again and again endlessly without success. The dmesg of the endless resets is attached. Marek On Sun, Oct 13, 2013 at 2:47 PM, Christian König wrote: I've figured out what was wrong with the patch. We need to reset the "needs_reset" flag earlier, otherwise the IB test might think we are in a lockup and aborts the reset after waiting for the minimum timeout period. Please try the attached patch instead. Thanks, Christian. Am 09.10.2013 14:04, schrieb Marek Olšák: The ring test of the first compute ring always fails and it shouldn't affect the GPU reset in any way. I can't tell if the deadlock issue is fixed, because the GPU reset usually fails with your patch. It always succeeded without your patch. Marek On Wed, Oct 9, 2013 at 1:09 PM, Christian König wrote: Mhm, that doesn't looks like anything related but more like the reset of the compute ring didn't worked. How often does that happen? And do you still get the problem where X waits for a fence that never comes back? Christian. Am 09.10.2013 12:36, schrieb Marek Olšák: I'm afraid your patch sometimes causes the GPU reset to fail, which had never happened before IIRC. The dmesg log from the failure is attached. Marek On Tue, Oct 8, 2013 at 6:21 PM, Christian König wrote: Hi Marek, please try the attached patch as a replacement for your signaling all fences patch. I'm not 100% sure if it fixes all issues, but it's at least a start. Thanks, Christian. Am 07.10.2013 13:08, schrieb Christian König: First of all, I can't complain about the reliability of the hardware GPU reset. It's mostly the kernel driver that happens to run into a deadlock at the same time. Alex and I spend quite some time on making this reliable again after activating more rings and adding VM support. The main problem is that I couldn't figure out where the CPU deadlock comes from, cause I couldn't reliable reproduce the issue. What is the content of /proc//task/*/stack and sys/kernel/debug/dri/0/radeon_fence_info when the X server is stuck in the deadlock situation? I'm pretty sure that we nearly always have a problem when two threads are waiting for fences on one of them detects that we have a lockup while the other one keeps holding the exclusive lock. Signaling all fences might work around that problem, but it probably would be better to fix the underlying issue. Going to take a deeper look into it. Christian. Am 03.10.2013 02:45, schrieb Marek Olšák: First of all, I can't complain about the reliability of the hardware GPU reset. It's mostly the kernel driver that happens to run into a deadlock at the same time. Regarding the issue with fences, the problem is that the GPU reset completes successfully according to dmesg, but X doesn't respond. I can move the cursor on the screen, but I can't do anything else and the UI is frozen. gdb says that X is stuck in GEM_WAIT_IDLE. I can easily reproduce this, because it's the most common reason why a GPU lockup leads to frozen X. The GPU actually recovers, but X is hung. I can't tell whether the fences are just not signalled or whether there is actually a real CPU deadlock I can't see. This patch makes the problem go away and GPU resets are successful (except for extreme cases, see below). With a small enough lockup timeout, the lockups are just a minor annoyance and I thought I could get through a piglit run just with a few tens or hundreds of GPU resets... A different type of deadlock showed up, though it needs a lot of concurrently-running apps like piglit. What happened is that the kernel driver was stuck/deadlocked in radeon_cs_ioctl presumably due to a GPU hang while holding onto the exclusive lock, and another thread wanting to do the GPU reset was unable to acquire the lock. That said, I will use the patch locally, because it helps a lot. I got a few lockups while writing this email and I'm glad I didn't have to reboot. Marek On Wed, Oct 2, 2013 at 4:50 PM, Christian König wrote: Possible, but I would rather guess that this doesn't work because the IB test runs into a deadlock situation and so the GPU reset never fully completes. Can you reproduce the problem? If you want to make GPU resets more reliable I would rather suggest to remove the ring lock dependency. Then we should try to give all the fence wait functions a (reliable) timeout and move reset handling a layer up into the ioctl functions. But for this you need to rip out the old PM code first. Christian. Marek Olšák schrieb: I'm afraid signalling the fences with an IB test is not reliable. Marek On Wed, Oct 2, 2013 at 3:52 PM, Christian König wrote:
[Bug 68792] Problems during playback of h264 files using UVD and VLC on AMD E-350 CPU
https://bugs.freedesktop.org/show_bug.cgi?id=68792 --- Comment #11 from Grigori Goronzy --- (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > (In reply to comment #5) > > > > You have to enable VDPAU output as well. > > > > > > Sorry, but where and how? > > > In VLC? > > > *.conf file? > > > > > > > In preferences go to the "Video" tab and select VDPAU from the list of > > outputs. > > I didn't have VDPAU, there. > That's why I'm asking. > Have a look at my attachments. > VDPAU is only enable under "Input/Codecs". > Is my VLC version missing something? > Yes, you do not have VDPAU video output support enabled in your VLC build. You may need a newer version (>= 0.6) of libvdpau and recent VLC master. > > With that I get only every several seconds one frame but good audio. > > lib/gallium> vlc /data/Filme/Serenity\ -\ HD\ DVD\ Trailer.mp4 > VLC media player 2.1.0 Rincewind (revision 2.1.0-0-gedd8835) > [0x8a94290] main interface error: no suitable interface module > [0x89973f8] main libvlc error: interface "globalhotkeys,none" initialization > failed > [0x89973f8] main libvlc: VLC wird mit dem Standard-Interface ausgeführt. > Benutzen Sie 'cvlc', um VLC ohne Interface zu verwenden. > [0xb4a306c0] avcodec decoder: Using G3DVL VDPAU Driver Shared Library > version 1.0 for hardware decoding. > [0xb4a306c0] avcodec decoder: Using G3DVL VDPAU Driver Shared Library > version 1.0 for hardware decoding. > [0xb4a402f0] main vout display error: Failed to resize display > [0xb4a306c0] avcodec decoder error: more than 5 seconds of late video -> > dropping frame (computer too slow ?) > [0xb4a306c0] avcodec decoder error: more than 5 seconds of late video -> > dropping frame (computer too slow ?) > [0xb4a306c0] avcodec decoder error: more than 5 seconds of late video -> > dropping frame (computer too slow ?) Please try again with latest Mesa, updated patches have been committed. I can play high-bitrate 1080p files without any framedrops and reasonable CPU load (~40-50%) on an E-450 now, even without VDPAU video output, which means that the inefficient readback path is used. With VDPAU video output enabled on VLC master, CPU usage is much lower. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 60827] X under radeon driver crashes after resuming from hibernation
https://bugzilla.kernel.org/show_bug.cgi?id=60827 --- Comment #8 from archie...@gmail.com --- I did some more digging : the hibernation problem is already present in kernel 3.9.11 while it is absent in 3.9.9. So, it seems that it was introduced either in 3.9.10 or 3.9.11. The last kernel that I could check is 3.11.3 and still poses the same problem. I hope that this will help to solve the problem. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 67187] Radeon HD6950: UVD not responding, trying to reset the VCPU
https://bugs.freedesktop.org/show_bug.cgi?id=67187 Christian König changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #19 from Christian König --- Sounds good, please try the newest 3.12 rc first before opening another bug report about the playback artifacts. I've fixed a couple of different bugs in this release and I'm not sure they got all backported yet. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 70439] Mobility 4570: System freezes after ~5s of enabling audio via xrandr
https://bugs.freedesktop.org/show_bug.cgi?id=70439 --- Comment #2 from Christian König --- Did you started audio before enabling it with "xrandr --output HDMI-0 --set audio auto" ? -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Old: i810 reclaim buffers deadlock
On Sun, Oct 13, 2013 at 8:50 PM, Paul Rogers wrote: > Ancient history, I know, apologies for that, but I can't see my way to a > solution and need help. > > Arguments: i815, kernel 2.6.34.14, XOrg-7.2, driver > xf86-video-i810-1.6.5/1.7.4 > > I'm hitting the old buffer reclaim deadlock problem. Is there a > compatible kernel patch for 2.6.34 or a version of the X driver that > will fix the error? Is there a path to resolution that doesn't involve > wholesale changes? The stuff I get from Google is quite confusing as to > it's application. I've "fixed" this in commit 87499ffdcb1c70f66988cd8febc4ead0ba2f9118 Author: Daniel Vetter Date: Tue Oct 25 23:51:24 2011 +0200 drm/i810: cleanup reclaim_buffers which is in v3.3 and later. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
