[PATCH v2 09/12] regulator: register dependency parser for firmware nodes
On Wed, Jul 01, 2015 at 11:41:04AM +0200, Tomeu Vizoso wrote: > So others can find out what depends on regulators, as specified > in bindings/regulator/regulator.txt. Reviewed-by: Mark Brown from a regulator point of view. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/d182932d/attachment.sig>
[PATCH 2/2 V5] regmap: Apply optional delay in multi_reg_write/register_patch
On Thu, Jul 16, 2015 at 04:36:22PM +0100, Nariman Poushin wrote: > + > + if (regs[i].delay_us) > + udelay(regs[i].delay_us); This is a bit funky. While Takashi is correct that we could be running in a spinlock equally this will mean that we could end up with some really long busy waits. It feels like we should at least make an effort to complain about that, print a warning or something. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/006edd00/attachment.sig>
[alsa-devel] [PATCH 1/2] V4 regmap: Use reg_sequence for multi_reg_write / register_patch
On Thu, Jul 16, 2015 at 04:45:25PM +0100, Nariman Poushin wrote: > I will resend with a cover letter explaining the change from the previous > patch set if that is the right thing to do. No, that's fine. If you want to fix something like that just reply to the cover letter with the extra information. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/cc443ef9/attachment-0001.sig>
[Bug 91136] [tahiti xt] portal2/dota2 glitchy without R600_DEBUG=switch_on_eop
https://bugs.freedesktop.org/show_bug.cgi?id=91136 --- Comment #3 from Gustaw Smolarczyk --- I can confirm that with Portal 2. It happens on my Tahiti Pro too. And R600_DEBUG=switch_on_eop fixes this issue. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/cf3f09b7/attachment.html>
[PATCH v2 01/12] device: property: delay device-driver matches
On Wed, Jul 01, 2015 at 11:40:56AM +0200, Tomeu Vizoso wrote: > Delay matches of platform devices until late_initcall, when we are sure > that all built-in drivers have been registered already. This is needed > to prevent deferred probes because of some dependencies' drivers not > having registered yet. I have to say I'm still not 100% clear that special casing platform devices makes sense here - I can see that platform devices are usually the first devices to instantiate but there are other kinds of devices and it's not obvious what the benefit of specifically picking out platform devices as opposed to just deferring all devices is. -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/0afe9ccc/attachment.sig>
[PATCH 2/2] drm/i915: Don't reprobe on resume
On 7/16/15, Daniel Vetter wrote: > You only get a hotplug event when something has actually changed, not for > every suspend/resume. Sure. But what about the case where something did get plugged/unplugged while suspended. That's what I was referring to, sorry for not being clear. Rui
[PATCH] drm: atmel-hlcdc: fix vblank initial state
From: Boris Brezillon
drm_vblank_on() now warns on nested use or if vblank is not properly
initialized. This patch fixes Atmel HLCDC vblank initial state.
Signed-off-by: Boris Brezillon
Reported-by: Sylvain Rochet
---
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 1 +
drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 12 ++--
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index f69b925..5ae5c69 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -355,6 +355,7 @@ int atmel_hlcdc_crtc_create(struct drm_device *dev)
planes->overlays[i]->base.possible_crtcs = 1 << crtc->id;
drm_crtc_helper_add(&crtc->base, &lcdc_crtc_helper_funcs);
+ drm_crtc_vblank_reset(&crtc->base);
dc->crtc = &crtc->base;
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
index 60b0c13..6fad1f9 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
@@ -313,20 +313,20 @@ static int atmel_hlcdc_dc_load(struct drm_device *dev)
pm_runtime_enable(dev->dev);
- ret = atmel_hlcdc_dc_modeset_init(dev);
+ ret = drm_vblank_init(dev, 1);
if (ret < 0) {
- dev_err(dev->dev, "failed to initialize mode setting\n");
+ dev_err(dev->dev, "failed to initialize vblank\n");
goto err_periph_clk_disable;
}
- drm_mode_config_reset(dev);
-
- ret = drm_vblank_init(dev, 1);
+ ret = atmel_hlcdc_dc_modeset_init(dev);
if (ret < 0) {
- dev_err(dev->dev, "failed to initialize vblank\n");
+ dev_err(dev->dev, "failed to initialize mode setting\n");
goto err_periph_clk_disable;
}
+ drm_mode_config_reset(dev);
+
pm_runtime_get_sync(dev->dev);
ret = drm_irq_install(dev, dc->hlcdc->irq);
pm_runtime_put_sync(dev->dev);
--
2.1.4
[PATCH 2/2] drm/i915: Don't reprobe on resume
On Thu, Jul 16, 2015 at 04:32:44PM +0100, Chris Wilson wrote: > On Thu, Jul 16, 2015 at 04:47:51PM +0200, Daniel Vetter wrote: > > If we don't force the connector state to unknown there's no reason any > > more to force a reprobe. Also no other driver bothers with this, so > > probably it's not required - userspace handles lid/resume events > > through other channels already. > > No, we don't. We don't synthesize any events at all for changing > connectors whilst suspended and userspace doesn't know about being > suspended. The problem is that since commit 816da85a0990c2b52cfffa77637d1c770d6790e9 Author: Daniel Vetter Date: Tue Oct 23 18:23:33 2012 + drm: handle HPD and polled connectors separately this has partially been broken (we only checked hpd connectors and not all of them), and apparently no one noticed or complained. Also none of the other drivers check this either. If we really need this then we need to fix it correctly, but right now I don't see much evidence for this really. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 2/2] drm/i915: Don't reprobe on resume
On Thu, Jul 16, 2015 at 07:41:14PM +0200, Rui Tiago Cação Matos wrote: > On Thu, Jul 16, 2015 at 5:32 PM, Chris Wilson > wrote: > > On Thu, Jul 16, 2015 at 04:47:51PM +0200, Daniel Vetter wrote: > >> If we don't force the connector state to unknown there's no reason any > >> more to force a reprobe. Also no other driver bothers with this, so > >> probably it's not required - userspace handles lid/resume events > >> through other channels already. > > > > No, we don't. We don't synthesize any events at all for changing > > connectors whilst suspended > > I haven't tried this patch yet but note that even the current kernel > (4.1.2) isn't sending HOTPLUG uevents out in precisely that case. It > would be nice if that got fixed. You only get a hotplug event when something has actually changed, not for every suspend/resume. > > userspace doesn't know about being > > suspended. > > For GNOME, we just rely on systemd to suspend so we do know when we > resume and we can easily trigger a reprobe then. It's up to you to > decide if this should be left to userspace but please > advertise/document it clearly. I'm not fully sure, but I think all other drivers don't trigger a probe over suspend/resume either. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 1/8] drm/bochs: phase 1 - use the transitional helpers
On Thu, Jul 16, 2015 at 05:49:43PM +0200, Gerd Hoffmann wrote: > On Do, 2015-07-16 at 20:20 +0800, John Hunter wrote: > > --- a/drivers/gpu/drm/bochs/bochs_kms.c > > +++ b/drivers/gpu/drm/bochs/bochs_kms.c > > @@ -10,6 +10,11 @@ > > > > static int defx = 1024; > > static int defy = 768; > > +static u64 gpu_addr = 0; > > That isn't going to fly. Guess you could it that into struct > bochs_framebuffer. Right I completely missed this in the prelimary review I've done. Simplest solution would be to remove gpu_addr and just lookup the bo offset again using bochs_bo_gpu_offset. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PATCH 8/8] drm/bochs: atomic dpms support
From: Zhao Junwang
- use ->disable() and ->enable() for crct and plane
- use drm_atomic_helper_connector_dpms for connector
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/bochs/bochs_kms.c | 34 ++
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 599f367..eccd0a7 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -23,16 +23,20 @@ MODULE_PARM_DESC(defy, "default y resolution");
/* -- */
-static void bochs_crtc_dpms(struct drm_crtc *crtc, int mode)
+static void bochs_crtc_enable(struct drm_crtc *crtc)
{
- switch (mode) {
- case DRM_MODE_DPMS_ON:
- case DRM_MODE_DPMS_STANDBY:
- case DRM_MODE_DPMS_SUSPEND:
- case DRM_MODE_DPMS_OFF:
- default:
+ if (crtc->enabled)
return;
- }
+
+ crtc->enabled = true;
+}
+
+static void bochs_crtc_disable(struct drm_crtc *crtc)
+{
+ if (!crtc->enabled)
+ return;
+
+ crtc->enabled = false;
}
static bool bochs_crtc_mode_fixup(struct drm_crtc *crtc,
@@ -71,7 +75,8 @@ static const struct drm_crtc_funcs bochs_crtc_funcs = {
};
static const struct drm_crtc_helper_funcs bochs_helper_funcs = {
- .dpms = bochs_crtc_dpms,
+ .enable = bochs_crtc_enable,
+ .disable = bochs_crtc_disable,
.mode_fixup = bochs_crtc_mode_fixup,
.mode_set_nofb = bochs_crtc_mode_set_nofb,
.commit = bochs_crtc_commit,
@@ -204,7 +209,11 @@ static void bochs_encoder_mode_set(struct drm_encoder
*encoder,
{
}
-static void bochs_encoder_dpms(struct drm_encoder *encoder, int state)
+static void bochs_encoder_enable(struct drm_encoder *encoder)
+{
+}
+
+static void bochs_encoder_disable(struct drm_encoder *encoder)
{
}
@@ -213,7 +222,8 @@ static void bochs_encoder_commit(struct drm_encoder
*encoder)
}
static const struct drm_encoder_helper_funcs bochs_encoder_helper_funcs = {
- .dpms = bochs_encoder_dpms,
+ .enable = bochs_encoder_enable,
+ .disable = bochs_encoder_disable,
.mode_fixup = bochs_encoder_mode_fixup,
.mode_set = bochs_encoder_mode_set,
.commit = bochs_encoder_commit,
@@ -286,7 +296,7 @@ struct drm_connector_helper_funcs
bochs_connector_connector_helper_funcs = {
};
struct drm_connector_funcs bochs_connector_connector_funcs = {
- .dpms = drm_helper_connector_dpms,
+ .dpms = drm_atomic_helper_connector_dpms,
.detect = bochs_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = drm_connector_cleanup,
--
1.7.10.4
[PATCH 7/8] drm/bochs: phase 3: switch to drm_atomic_helper_page_flip
From: Zhao Junwang
PageFlips now use the atomic helper to work through the atomic
modesetting API.
v2: -Since driver is now fully atomic, we should add DRIVER_ATOMIC
to .driver_features.
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/bochs/bochs_drv.c |2 +-
drivers/gpu/drm/bochs/bochs_kms.c | 22 +-
2 files changed, 2 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
b/drivers/gpu/drm/bochs/bochs_drv.c
index 98837bd..fc31643 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -79,7 +79,7 @@ static const struct file_operations bochs_fops = {
};
static struct drm_driver bochs_driver = {
- .driver_features= DRIVER_GEM | DRIVER_MODESET,
+ .driver_features= DRIVER_GEM | DRIVER_MODESET | DRIVER_ATOMIC,
.load = bochs_load,
.unload = bochs_unload,
.set_busid = drm_pci_set_busid,
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index f0e93e1..599f367 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -59,32 +59,12 @@ static void bochs_crtc_gamma_set(struct drm_crtc *crtc, u16
*red, u16 *green,
{
}
-static int bochs_crtc_page_flip(struct drm_crtc *crtc,
- struct drm_framebuffer *fb,
- struct drm_pending_vblank_event *event,
- uint32_t page_flip_flags)
-{
- struct bochs_device *bochs =
- container_of(crtc, struct bochs_device, crtc);
- struct drm_framebuffer *old_fb = crtc->primary->fb;
- unsigned long irqflags;
-
- crtc->primary->fb = fb;
- drm_helper_crtc_mode_set_base(crtc, 0, 0, old_fb);
- if (event) {
- spin_lock_irqsave(&bochs->dev->event_lock, irqflags);
- drm_send_vblank_event(bochs->dev, -1, event);
- spin_unlock_irqrestore(&bochs->dev->event_lock, irqflags);
- }
- return 0;
-}
-
/* These provide the minimum set of functions required to handle a CRTC */
static const struct drm_crtc_funcs bochs_crtc_funcs = {
.gamma_set = bochs_crtc_gamma_set,
.set_config = drm_atomic_helper_set_config,
.destroy = drm_crtc_cleanup,
- .page_flip = bochs_crtc_page_flip,
+ .page_flip = drm_atomic_helper_page_flip,
.reset = drm_atomic_helper_crtc_reset,
.atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
--
1.7.10.4
[PATCH 6/8] drm/bochs: phase 3: provide a custom ->atomic_commit implementation
From: Zhao Junwang
This supports the asynchronous commits, required for page-flipping
Since it's virtual hw it's ok to commit async stuff right away, we
never have to wait for vblank.
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/bochs/bochs_mm.c |9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index c1d819c..37ac2ca 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -545,8 +545,15 @@ bochs_user_framebuffer_create(struct drm_device *dev,
return &bochs_fb->base;
}
+static int bochs_atomic_commit(struct drm_device *dev,
+struct drm_atomic_state *a,
+bool async)
+{
+ return drm_atomic_helper_commit(dev, a, false);
+}
+
const struct drm_mode_config_funcs bochs_mode_funcs = {
.fb_create = bochs_user_framebuffer_create,
.atomic_check = drm_atomic_helper_check,
- .atomic_commit = drm_atomic_helper_commit,
+ .atomic_commit = bochs_atomic_commit,
};
--
1.7.10.4
[PATCH 5/8] drm/bochs: phase 3: use atomic .set_config helper
From: Zhao Junwang
Now that phase 1 and phase 2 are complete, switch .set_config helper
to use the atomic one.
-since .prepare() callbacks are no more needed, remove them
-.mode_set() and .mode_set_base() are no longer needed, remove
-as we are not using the transitional helper now, we can use the
drm_atomic_helper_plane_check_update this time.
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/bochs/bochs_kms.c | 24 ++--
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 2d2de7c..f0e93e1 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -50,10 +50,6 @@ static void bochs_crtc_mode_set_nofb(struct drm_crtc *crtc)
bochs_hw_setmode(bochs, &crtc->mode);
}
-static void bochs_crtc_prepare(struct drm_crtc *crtc)
-{
-}
-
static void bochs_crtc_commit(struct drm_crtc *crtc)
{
}
@@ -86,7 +82,7 @@ static int bochs_crtc_page_flip(struct drm_crtc *crtc,
/* These provide the minimum set of functions required to handle a CRTC */
static const struct drm_crtc_funcs bochs_crtc_funcs = {
.gamma_set = bochs_crtc_gamma_set,
- .set_config = drm_crtc_helper_set_config,
+ .set_config = drm_atomic_helper_set_config,
.destroy = drm_crtc_cleanup,
.page_flip = bochs_crtc_page_flip,
.reset = drm_atomic_helper_crtc_reset,
@@ -97,10 +93,7 @@ static const struct drm_crtc_funcs bochs_crtc_funcs = {
static const struct drm_crtc_helper_funcs bochs_helper_funcs = {
.dpms = bochs_crtc_dpms,
.mode_fixup = bochs_crtc_mode_fixup,
- .mode_set = drm_helper_crtc_mode_set,
- .mode_set_base = drm_helper_crtc_mode_set_base,
.mode_set_nofb = bochs_crtc_mode_set_nofb,
- .prepare = bochs_crtc_prepare,
.commit = bochs_crtc_commit,
};
@@ -162,7 +155,15 @@ static void bochs_plane_cleanup_fb(struct drm_plane *plane,
static int bochs_plane_atomic_check(struct drm_plane *plane,
struct drm_plane_state *plane_state)
{
- return 0;
+ bool visible;
+
+ if (!plane_state->fb)
+ return 0;
+
+ return drm_atomic_helper_plane_check_update(plane_state,
+ DRM_PLANE_HELPER_NO_SCALING,
+ DRM_PLANE_HELPER_NO_SCALING,
+ false, &visible);
}
static void bochs_plane_atomic_update(struct drm_plane *plane,
@@ -227,10 +228,6 @@ static void bochs_encoder_dpms(struct drm_encoder
*encoder, int state)
{
}
-static void bochs_encoder_prepare(struct drm_encoder *encoder)
-{
-}
-
static void bochs_encoder_commit(struct drm_encoder *encoder)
{
}
@@ -239,7 +236,6 @@ static const struct drm_encoder_helper_funcs
bochs_encoder_helper_funcs = {
.dpms = bochs_encoder_dpms,
.mode_fixup = bochs_encoder_mode_fixup,
.mode_set = bochs_encoder_mode_set,
- .prepare = bochs_encoder_prepare,
.commit = bochs_encoder_commit,
};
--
1.7.10.4
[PATCH 4/8] drm/bochs: phase 3: for plane updates: switch to atomic helper internally
From: Zhao Junwang
- planes:
drm_atomic_helper_update_plane()
drm_atomic_helper_diable_plane()
- Driver:
drm_atomic_helper_check()
drm_atomic_helper_commit()
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/bochs/bochs_kms.c |4 ++--
drivers/gpu/drm/bochs/bochs_mm.c |2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index e5fa125..2d2de7c 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -177,8 +177,8 @@ static void bochs_plane_atomic_update(struct drm_plane
*plane,
}
static const struct drm_plane_funcs bochs_plane_funcs = {
- .update_plane = drm_plane_helper_update,
- .disable_plane = drm_plane_helper_disable,
+ .update_plane = drm_atomic_helper_update_plane,
+ .disable_plane = drm_atomic_helper_disable_plane,
.reset = drm_atomic_helper_plane_reset,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
diff --git a/drivers/gpu/drm/bochs/bochs_mm.c b/drivers/gpu/drm/bochs/bochs_mm.c
index 66286ff..c1d819c 100644
--- a/drivers/gpu/drm/bochs/bochs_mm.c
+++ b/drivers/gpu/drm/bochs/bochs_mm.c
@@ -547,4 +547,6 @@ bochs_user_framebuffer_create(struct drm_device *dev,
const struct drm_mode_config_funcs bochs_mode_funcs = {
.fb_create = bochs_user_framebuffer_create,
+ .atomic_check = drm_atomic_helper_check,
+ .atomic_commit = drm_atomic_helper_commit,
};
--
1.7.10.4
[PATCH 3/8] drm/bochs: stop looking at legacy state
From: Zhao Junwang with transitional helpers we've used the new callbacks, but control flow was still old, but with atomic first step is to call atomic_check, then prepare_fb, and so on, by this time, we can not look at any legacy state like plane->fb or crtc->enabled, because they are updated at the very end. Cc: Maarten Lankhorst Cc: Daniel Vetter Signed-off-by: Zhao Junwang --- drivers/gpu/drm/bochs/bochs_kms.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bochs/bochs_kms.c b/drivers/gpu/drm/bochs/bochs_kms.c index a14bac4..e5fa125 100644 --- a/drivers/gpu/drm/bochs/bochs_kms.c +++ b/drivers/gpu/drm/bochs/bochs_kms.c @@ -123,10 +123,10 @@ static int bochs_plane_prepare_fb(struct drm_plane *plane, struct bochs_bo *bo; int ret; - if (WARN_ON(plane->fb == NULL)) + if (WARN_ON(fb == NULL)) return -EINVAL; - bochs_fb = to_bochs_framebuffer(plane->fb); + bochs_fb = to_bochs_framebuffer(fb); bo = gem_to_bochs_bo(bochs_fb->obj); ttm_bo_reserve(&bo->bo, true, false, false, NULL); -- 1.7.10.4
[PATCH 2/8] drm/bochs: phase 2: wire up state reset(), duplicate() and destroy
From: Zhao Junwang
Set CRTC, planes and connectors to use the default implementations
from the atomic helper library.
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/bochs/bochs_kms.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 1b66dd3..a14bac4 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -89,6 +89,9 @@ static const struct drm_crtc_funcs bochs_crtc_funcs = {
.set_config = drm_crtc_helper_set_config,
.destroy = drm_crtc_cleanup,
.page_flip = bochs_crtc_page_flip,
+ .reset = drm_atomic_helper_crtc_reset,
+ .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
};
static const struct drm_crtc_helper_funcs bochs_helper_funcs = {
@@ -176,6 +179,9 @@ static void bochs_plane_atomic_update(struct drm_plane
*plane,
static const struct drm_plane_funcs bochs_plane_funcs = {
.update_plane = drm_plane_helper_update,
.disable_plane = drm_plane_helper_disable,
+ .reset = drm_atomic_helper_plane_reset,
+ .atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
};
static const struct drm_plane_helper_funcs bochs_plane_helper_funcs = {
@@ -308,6 +314,9 @@ struct drm_connector_funcs bochs_connector_connector_funcs
= {
.detect = bochs_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = drm_connector_cleanup,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
};
static void bochs_connector_init(struct drm_device *dev)
@@ -341,6 +350,9 @@ int bochs_kms_init(struct bochs_device *bochs)
bochs_crtc_init(bochs->dev);
bochs_encoder_init(bochs->dev);
bochs_connector_init(bochs->dev);
+
+ drm_mode_config_reset(bochs->dev);
+
drm_mode_connector_attach_encoder(&bochs->connector,
&bochs->encoder);
--
1.7.10.4
[PATCH 1/8] drm/bochs: phase 1 - use the transitional helpers
From: Zhao Junwang
-register driver's own primary plane
-use drm_crtc_init_with_planes instead of drm_crtc_init
-split ->mode_set into:
1. set the new hw mode
2. update the primary plane (This is done by ->set_base)
-move what ->set_base do into ->atomic_update
-the new atomic infrastructure needs the ->mode_set_nofb callback
to update CRTC timings before setting any plane
-since the ->cleanup_fb can't fail, set the interruptible argument
of the ttm_bo_reserve to false, this make sure the ttm_bo_reserve
can't fail
v2: -add a few checks to plane's ->atomic_check, using
drm_plane_helper_check_update
v3: -polish the atomic_check, it does too much in v2, remove the
->disable_plane and ->set_config
v4: -use plane->state instead of old_state in
bochs_plane_atomic_update
v5: -just return 0 in plane ->atomic_check, i.e. remove what we
do in v2-v4
Cc: Maarten Lankhorst
Cc: Daniel Vetter
Signed-off-by: Zhao Junwang
---
drivers/gpu/drm/bochs/bochs.h |2 +
drivers/gpu/drm/bochs/bochs_kms.c | 159 -
2 files changed, 108 insertions(+), 53 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs.h b/drivers/gpu/drm/bochs/bochs.h
index 71f2687..2f10480 100644
--- a/drivers/gpu/drm/bochs/bochs.h
+++ b/drivers/gpu/drm/bochs/bochs.h
@@ -5,6 +5,7 @@
#include
#include
#include
+#include
#include
#include
@@ -72,6 +73,7 @@ struct bochs_device {
/* drm */
struct drm_device *dev;
+ struct drm_plane primary;
struct drm_crtc crtc;
struct drm_encoder encoder;
struct drm_connector connector;
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 26bcd03..1b66dd3 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -10,6 +10,11 @@
static int defx = 1024;
static int defy = 768;
+static u64 gpu_addr = 0;
+
+static const uint32_t bochs_primary_formats[] = {
+ DRM_FORMAT_XRGB,
+};
module_param(defx, int, 0444);
module_param(defy, int, 0444);
@@ -37,59 +42,12 @@ static bool bochs_crtc_mode_fixup(struct drm_crtc *crtc,
return true;
}
-static int bochs_crtc_mode_set_base(struct drm_crtc *crtc, int x, int y,
- struct drm_framebuffer *old_fb)
+static void bochs_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct bochs_device *bochs =
container_of(crtc, struct bochs_device, crtc);
- struct bochs_framebuffer *bochs_fb;
- struct bochs_bo *bo;
- u64 gpu_addr = 0;
- int ret;
- if (old_fb) {
- bochs_fb = to_bochs_framebuffer(old_fb);
- bo = gem_to_bochs_bo(bochs_fb->obj);
- ret = ttm_bo_reserve(&bo->bo, true, false, false, NULL);
- if (ret) {
- DRM_ERROR("failed to reserve old_fb bo\n");
- } else {
- bochs_bo_unpin(bo);
- ttm_bo_unreserve(&bo->bo);
- }
- }
-
- if (WARN_ON(crtc->primary->fb == NULL))
- return -EINVAL;
-
- bochs_fb = to_bochs_framebuffer(crtc->primary->fb);
- bo = gem_to_bochs_bo(bochs_fb->obj);
- ret = ttm_bo_reserve(&bo->bo, true, false, false, NULL);
- if (ret)
- return ret;
-
- ret = bochs_bo_pin(bo, TTM_PL_FLAG_VRAM, &gpu_addr);
- if (ret) {
- ttm_bo_unreserve(&bo->bo);
- return ret;
- }
-
- ttm_bo_unreserve(&bo->bo);
- bochs_hw_setbase(bochs, x, y, gpu_addr);
- return 0;
-}
-
-static int bochs_crtc_mode_set(struct drm_crtc *crtc,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode,
- int x, int y, struct drm_framebuffer *old_fb)
-{
- struct bochs_device *bochs =
- container_of(crtc, struct bochs_device, crtc);
-
- bochs_hw_setmode(bochs, mode);
- bochs_crtc_mode_set_base(crtc, x, y, old_fb);
- return 0;
+ bochs_hw_setmode(bochs, &crtc->mode);
}
static void bochs_crtc_prepare(struct drm_crtc *crtc)
@@ -116,7 +74,7 @@ static int bochs_crtc_page_flip(struct drm_crtc *crtc,
unsigned long irqflags;
crtc->primary->fb = fb;
- bochs_crtc_mode_set_base(crtc, 0, 0, old_fb);
+ drm_helper_crtc_mode_set_base(crtc, 0, 0, old_fb);
if (event) {
spin_lock_irqsave(&bochs->dev->event_lock, irqflags);
drm_send_vblank_event(bochs->dev, -1, event);
@@ -136,8 +94,9 @@ static const struct drm_crtc_funcs bochs_crtc_funcs = {
static const struct drm_crtc_helper_funcs bochs_helper_funcs = {
.dpms = bochs_crtc_dpms,
.mode_fixup = bochs_crtc_mode_fixup,
- .mode_set = bochs_crtc_mode_set,
- .mode_set_base = bochs_crtc_mode_set_base,
+ .mode_set = drm_helper_crtc_mode_set,
+ .mode_set_base
[PATCH 0/8] drm/bochs: convert bochs to atomic mode-setting
From: Zhao Junwang This patch series aim to convert DRM_BOCHS to atomic mode-setting. I did this mostly reference Gustavo Padovan's patch series on drm/exynos conversion. Zhao Junwang (8): drm/bochs: phase 1 - use the transitional helpers drm/bochs: phase 2: wire up state reset(), duplicate() and destroy drm/bochs: stop looking at legacy state drm/bochs: phase 3: for plane updates: switch to atomic helper internally drm/bochs: phase 3: use atomic .set_config helper drm/bochs: phase 3: provide a custom ->atomic_commit implementation drm/bochs: phase 3: switch to drm_atomic_helper_page_flip drm/bochs: atomic dpms support drivers/gpu/drm/bochs/bochs.h |2 + drivers/gpu/drm/bochs/bochs_drv.c |2 +- drivers/gpu/drm/bochs/bochs_kms.c | 221 +++-- drivers/gpu/drm/bochs/bochs_mm.c |9 ++ 4 files changed, 148 insertions(+), 86 deletions(-) -- 1.7.10.4
[PATCH 2/2] drm/i915: Don't reprobe on resume
On Thu, Jul 16, 2015 at 5:32 PM, Chris Wilson wrote: > On Thu, Jul 16, 2015 at 04:47:51PM +0200, Daniel Vetter wrote: >> If we don't force the connector state to unknown there's no reason any >> more to force a reprobe. Also no other driver bothers with this, so >> probably it's not required - userspace handles lid/resume events >> through other channels already. > > No, we don't. We don't synthesize any events at all for changing > connectors whilst suspended I haven't tried this patch yet but note that even the current kernel (4.1.2) isn't sending HOTPLUG uevents out in precisely that case. It would be nice if that got fixed. > userspace doesn't know about being > suspended. For GNOME, we just rely on systemd to suspend so we do know when we resume and we can easily trigger a reprobe then. It's up to you to decide if this should be left to userspace but please advertise/document it clearly. Thanks, Rui
[PATCH 1/2] drm: Stop resetting connector state to unknown
On Thu, Jul 16, 2015 at 4:47 PM, Daniel Vetter wrote: > It's causing piles of issues since we've stopped forcing full detect > cycles in the sysfs interfaces with I tested this one on top of 4.1.2 and it does what it says on the tin, i.e. after resuming I get the connected/disconnected strings on the /sys/class/drm/*/status files. Rui
[Bug 91302] radeon.audio=1 causes issues with 7950
https://bugs.freedesktop.org/show_bug.cgi?id=91302 Max Qia changed: What|Removed |Added Summary|radeon.audio=1 causes weird |radeon.audio=1 causes |issues with 7950|issues with 7950 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/494d6db0/attachment.html>
[PATCH v3 5/5] [media] imx-ipu: Add i.MX IPUv3 scaler driver
From: Sascha Hauer
This patch adds support for hardware accelerated scaling and color
space conversion between memory buffers using the IPUv3 IC.
Since the maximum output size of the IC unit is 1024x1024 pixels, multiple
IC tasks with overlapping tiles are used internally to scale and convert
larger frames.
The IC operates with a burst size of at least 8 pixels. Depending on the
frame width and scaling factor, up to 7 junk pixels may be written after
the end of the frame. The sizeimage is increased accordingly.
Signed-off-by: Sascha Hauer
Signed-off-by: Michael Olbrich
Signed-off-by: Philipp Zabel
---
Changes since v2:
- Disabled USERPTR memory, hardware doesn't support it.
- Embedded struct video_device in ipu_scale_dev.
- Set icc pointer to NULL on error.
- Fixed module description.
---
drivers/media/platform/imx/Kconfig | 9 +
drivers/media/platform/imx/Makefile | 1 +
drivers/media/platform/imx/imx-ipu-scaler.c | 859
drivers/media/platform/imx/imx-ipu.c| 2 +-
drivers/media/platform/imx/imx-ipu.h| 1 +
5 files changed, 871 insertions(+), 1 deletion(-)
create mode 100644 drivers/media/platform/imx/imx-ipu-scaler.c
diff --git a/drivers/media/platform/imx/Kconfig
b/drivers/media/platform/imx/Kconfig
index a90c973..4694367 100644
--- a/drivers/media/platform/imx/Kconfig
+++ b/drivers/media/platform/imx/Kconfig
@@ -1,2 +1,11 @@
config VIDEO_IMX_IPU_COMMON
tristate
+
+config VIDEO_IMX_IPU_SCALER
+ tristate "i.MX5/6 IPUv3 based image scaler driver"
+ depends on VIDEO_DEV && IMX_IPUV3_CORE
+ select VIDEOBUF2_DMA_CONTIG
+ select VIDEO_IMX_IPU_COMMON
+ select V4L2_MEM2MEM_DEV
+ ---help---
+ This is a v4l2 scaler video driver for the IPUv3 on i.MX5/6.
diff --git a/drivers/media/platform/imx/Makefile
b/drivers/media/platform/imx/Makefile
index 5de119c..f20aa0b 100644
--- a/drivers/media/platform/imx/Makefile
+++ b/drivers/media/platform/imx/Makefile
@@ -1 +1,2 @@
obj-$(CONFIG_VIDEO_IMX_IPU_COMMON) += imx-ipu.o
+obj-$(CONFIG_VIDEO_IMX_IPU_SCALER) += imx-ipu-scaler.o
diff --git a/drivers/media/platform/imx/imx-ipu-scaler.c
b/drivers/media/platform/imx/imx-ipu-scaler.c
new file mode 100644
index 000..6c6d0aa
--- /dev/null
+++ b/drivers/media/platform/imx/imx-ipu-scaler.c
@@ -0,0 +1,860 @@
+/*
+ * i.MX IPUv3 scaler driver
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix
+ *
+ * based on the mem2mem test driver
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+#include "imx-ipu.h"
+
+#define MIN_W 32
+#define MIN_H 32
+#define MAX_W 4096
+#define MAX_H 4096
+#define DIM_ALIGN_MASK 0x08 /* 8-alignment for dimensions */
+
+/* Flags that indicate a format can be used for capture/output */
+#define MEM2MEM_CAPTURE(1 << 0)
+#define MEM2MEM_OUTPUT (1 << 1)
+
+#define MEM2MEM_NAME "imx-ipuv3-scale"
+
+/* Per queue */
+#define MEM2MEM_DEF_NUM_BUFS VIDEO_MAX_FRAME
+/* In bytes, per queue */
+#define MEM2MEM_VID_MEM_LIMIT (64 * 1024 * 1024)
+
+#define fh_to_ctx(__fh)container_of(__fh, struct ipu_scale_ctx, fh)
+
+enum {
+ V4L2_M2M_SRC = 0,
+ V4L2_M2M_DST = 1,
+};
+
+struct ipu_scale_dev {
+ struct v4l2_device v4l2_dev;
+ struct video_device vfd;
+ struct device *dev;
+ struct ipu_soc *ipu;
+
+ atomic_tnum_inst;
+ spinlock_t irqlock;
+
+ struct v4l2_m2m_dev *m2m_dev;
+ struct mutexdev_mutex;
+};
+
+/* Per-queue, driver-specific private data */
+struct ipu_scale_q_data {
+ struct v4l2_pix_format cur_fmt;
+ struct v4l2_rectrect;
+};
+
+struct ipu_scale_ctx {
+ struct ipu_scale_dev*ipu_scaler;
+
+ struct v4l2_fh fh;
+ struct vb2_alloc_ctx*alloc_ctx;
+ struct ipu_scale_q_data q_data[2];
+ struct work_struct work;
+ struct completion completion;
+ struct work_struct skip_run;
+ int error;
+ int aborting;
+ enum ipu_image_scale_ctrl ctrl;
+ struct image_convert_ctx *icc;
+ int num_tiles;
+};
+
+static struct ipu_scale_q_data *get_q_data(struct ipu_scale_ctx *ctx,
+ enum v4l2_buf_type type)
+{
+ switch (
[PATCH v3 4/5] [media] imx-ipu: Add ipu media common code
From: Sascha Hauer
Add video4linux API routines common to drivers for units that
accept or provide video data via the i.MX IPU IDMAC channels,
such as scaler or deinterlacer drivers.
Signed-off-by: Sascha Hauer
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
---
drivers/media/platform/Kconfig | 2 +
drivers/media/platform/Makefile | 1 +
drivers/media/platform/imx/Kconfig | 2 +
drivers/media/platform/imx/Makefile | 1 +
drivers/media/platform/imx/imx-ipu.c | 313 +++
drivers/media/platform/imx/imx-ipu.h | 35
6 files changed, 354 insertions(+)
create mode 100644 drivers/media/platform/imx/Kconfig
create mode 100644 drivers/media/platform/imx/Makefile
create mode 100644 drivers/media/platform/imx/imx-ipu.c
create mode 100644 drivers/media/platform/imx/imx-ipu.h
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index f6bed19..66c8d91 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -29,6 +29,8 @@ config VIDEO_VIA_CAMERA
source "drivers/media/platform/davinci/Kconfig"
+source "drivers/media/platform/imx/Kconfig"
+
source "drivers/media/platform/omap/Kconfig"
source "drivers/media/platform/blackfin/Kconfig"
diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile
index 114f9ab..c3438c2 100644
--- a/drivers/media/platform/Makefile
+++ b/drivers/media/platform/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SOC_CAMERA) += soc_camera/
obj-$(CONFIG_VIDEO_RENESAS_VSP1) += vsp1/
+obj-y += imx/
obj-y += omap/
obj-$(CONFIG_VIDEO_AM437X_VPFE)+= am437x/
diff --git a/drivers/media/platform/imx/Kconfig
b/drivers/media/platform/imx/Kconfig
new file mode 100644
index 000..a90c973
--- /dev/null
+++ b/drivers/media/platform/imx/Kconfig
@@ -0,0 +1,2 @@
+config VIDEO_IMX_IPU_COMMON
+ tristate
diff --git a/drivers/media/platform/imx/Makefile
b/drivers/media/platform/imx/Makefile
new file mode 100644
index 000..5de119c
--- /dev/null
+++ b/drivers/media/platform/imx/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VIDEO_IMX_IPU_COMMON) += imx-ipu.o
diff --git a/drivers/media/platform/imx/imx-ipu.c
b/drivers/media/platform/imx/imx-ipu.c
new file mode 100644
index 000..c1b8637
--- /dev/null
+++ b/drivers/media/platform/imx/imx-ipu.c
@@ -0,0 +1,313 @@
+/*
+ * i.MX IPUv3 common v4l2 support
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+
+#include "imx-ipu.h"
+
+static struct ipu_fmt ipu_fmt_yuv[] = {
+ {
+ .fourcc = V4L2_PIX_FMT_YUV420,
+ .name = "YUV 4:2:0 planar, YCbCr",
+ .bytes_per_pixel = 1,
+ }, {
+ .fourcc = V4L2_PIX_FMT_YVU420,
+ .name = "YUV 4:2:0 planar, YCrCb",
+ .bytes_per_pixel = 1,
+ }, {
+ .fourcc = V4L2_PIX_FMT_YUV422P,
+ .name = "YUV 4:2:2 planar, YCbCr",
+ .bytes_per_pixel = 1,
+ }, {
+ .fourcc = V4L2_PIX_FMT_NV12,
+ .name = "YUV 4:2:0 partial interleaved, YCbCr",
+ .bytes_per_pixel = 1,
+ }, {
+ .fourcc = V4L2_PIX_FMT_UYVY,
+ .name = "4:2:2, packed, UYVY",
+ .bytes_per_pixel = 2,
+ }, {
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .name = "4:2:2, packed, YUYV",
+ .bytes_per_pixel = 2,
+ },
+};
+
+static struct ipu_fmt ipu_fmt_rgb[] = {
+ {
+ .fourcc = V4L2_PIX_FMT_RGB32,
+ .name = "RGB888",
+ .bytes_per_pixel = 4,
+ }, {
+ .fourcc = V4L2_PIX_FMT_RGB24,
+ .name = "RGB24",
+ .bytes_per_pixel = 3,
+ }, {
+ .fourcc = V4L2_PIX_FMT_BGR24,
+ .name = "BGR24",
+ .bytes_per_pixel = 3,
+ }, {
+ .fourcc = V4L2_PIX_FMT_RGB565,
+ .name = "RGB565",
+ .bytes_per_pixel = 2,
+ },
+ {
+ .fourcc = V4L2_PIX_FMT_BGR32,
+ .name = "BGR888",
+ .bytes_per_pixel = 4,
+ },
+};
+
+struct ipu_fmt *ipu_find_fmt_yuv(unsigned int pixelformat)
+{
+ struct ipu_fmt *fmt;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(ipu_fmt_yuv); i++) {
+ fmt = &ipu_fmt_yuv[i];
+ if (fmt->fourcc == pixelformat)
+
[PATCH v3 3/5] gpu: ipu-v3: Register scaler platform device
This patch registers the scaler device using the IC post-processing task,
to be handled by a mem2mem scaler driver.
Signed-off-by: Philipp Zabel
---
drivers/gpu/ipu-v3/ipu-common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 6d2f39d..9846cec 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1026,6 +1026,8 @@ static const struct ipu_platform_reg client_reg[] = {
},
.reg_offset = IPU_CM_CSI1_REG_OFS,
.name = "imx-ipuv3-camera",
+ }, {
+ .name = "imx-ipuv3-scaler",
},
};
--
2.1.4
[PATCH v3 2/5] gpu: ipu-v3: Add mem2mem image conversion support to IC
This patch adds support for mem2mem scaling and colorspace conversion
using the IC module's post-processing task.
Scaling images larger than 1024x1024 is supported by tiling over multiple
IC scaling runs. Since the IDMAC and IC units have interesting and
different alignment limitations for buffer base addresses (left edges)
and burst size (row lengths), depending on input and output pixel formats,
the tile rectangles and scaling coefficients are chosen to minimize
distortion. Due to possible overlap, the tiles have to be rendered right
to left and bottom to top. Up to 7 pixels (depending on frame sizes and
scaling factor) have to be available after the end of the frame if the
width is not burst size aligned. The tiling code has a parameter to
optionally round frame sizes up or down and avoid overdraw in
compositing scenarios.
Signed-off-by: Sascha Hauer
Signed-off-by: Lucas Stach
Signed-off-by: Philipp Zabel
---
Changes since v2:
- Limit downscaling to 4:1
- Dropped currently unused rotator and deinterlacer channels
---
drivers/gpu/ipu-v3/ipu-ic.c | 754 +++-
include/video/imx-ipu-v3.h | 34 +-
2 files changed, 771 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-ic.c b/drivers/gpu/ipu-v3/ipu-ic.c
index 1dcb96c..7a79e46 100644
--- a/drivers/gpu/ipu-v3/ipu-ic.c
+++ b/drivers/gpu/ipu-v3/ipu-ic.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include "ipu-prv.h"
@@ -96,6 +97,11 @@ struct ic_task_bitfields {
u32 ic_cmb_galpha_bit;
};
+struct ic_task_channels {
+ u8 in;
+ u8 out;
+};
+
static const struct ic_task_regoffs ic_task_reg[IC_NUM_TASKS] = {
[IC_TASK_ENCODER] = {
.rsc = IC_PRP_ENC_RSC,
@@ -138,12 +144,41 @@ static const struct ic_task_bitfields
ic_task_bit[IC_NUM_TASKS] = {
},
};
+static const struct ic_task_channels ic_task_ch[IC_NUM_TASKS] = {
+ [IC_TASK_ENCODER] = {
+ .in = IPUV3_CHANNEL_MEM_IC_PRP_VF,
+ .out = IPUV3_CHANNEL_IC_PRP_ENC_MEM,
+ },
+ [IC_TASK_VIEWFINDER] = {
+ .in = IPUV3_CHANNEL_MEM_VDI_CUR,
+ .out = IPUV3_CHANNEL_IC_PRP_VF_MEM,
+ },
+ [IC_TASK_POST_PROCESSOR] = {
+ .in = IPUV3_CHANNEL_MEM_IC_PP,
+ .out = IPUV3_CHANNEL_IC_PP_MEM,
+ },
+};
+
+struct image_convert_ctx {
+ void (*complete)(void *ctx, int err);
+ void *complete_context;
+
+ struct list_head list;
+ struct ipu_image in;
+ struct ipu_image out;
+
+ void *freep;
+
+ u32 rsc;
+};
+
struct ipu_ic_priv;
struct ipu_ic {
enum ipu_ic_task task;
const struct ic_task_regoffs *reg;
const struct ic_task_bitfields *bit;
+ const struct ic_task_channels *ch;
enum ipu_color_space in_cs, g_in_cs;
enum ipu_color_space out_cs;
@@ -152,6 +187,15 @@ struct ipu_ic {
bool in_use;
struct ipu_ic_priv *priv;
+
+ struct ipuv3_channel *input_channel;
+ struct ipuv3_channel *output_channel;
+
+ struct list_head image_list;
+
+ struct workqueue_struct *workqueue;
+ struct work_struct work;
+ struct completion complete;
};
struct ipu_ic_priv {
@@ -168,7 +212,8 @@ static inline u32 ipu_ic_read(struct ipu_ic *ic, unsigned
offset)
return readl(ic->priv->base + offset);
}
-static inline void ipu_ic_write(struct ipu_ic *ic, u32 value, unsigned offset)
+static inline void ipu_ic_write(struct ipu_ic *ic, u32 value,
+ unsigned offset)
{
writel(value, ic->priv->base + offset);
}
@@ -446,32 +491,35 @@ int ipu_ic_task_init(struct ipu_ic *ic,
int in_width, int in_height,
int out_width, int out_height,
enum ipu_color_space in_cs,
-enum ipu_color_space out_cs)
+enum ipu_color_space out_cs,
+u32 rsc)
{
struct ipu_ic_priv *priv = ic->priv;
- u32 reg, downsize_coeff, resize_coeff;
+ u32 downsize_coeff, resize_coeff;
unsigned long flags;
int ret = 0;
- /* Setup vertical resizing */
- ret = calc_resize_coeffs(ic, in_height, out_height,
-&resize_coeff, &downsize_coeff);
- if (ret)
- return ret;
+ if (!rsc) {
+ /* Setup vertical resizing */
+ ret = calc_resize_coeffs(ic, in_height, out_height,
+&resize_coeff, &downsize_coeff);
+ if (ret)
+ return ret;
- reg = (downsize_coeff << 30) | (resize_coeff << 16);
+ rsc = (downsize_coeff << 30) | (resize_coeff << 16);
- /* Setup horizontal resizing */
- ret = calc_resize_coeffs(ic, in_width, out_width,
-&resize_coeff, &downsize_coeff);
- if (ret)
-
[PATCH v3 1/5] gpu: ipu-v3: Add missing IDMAC channel names
This patch adds the remaining missing IDMAC channel names: all VDIC
channels for deinterlacing and combining, the separate alpha channels
for the MEM->IC and MEM->DC ASYNC channels, and the DC read, command,
and output mask channels.
Signed-off-by: Philipp Zabel
---
include/video/imx-ipu-v3.h | 15 +++
1 file changed, 15 insertions(+)
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 85dedca..0cf0a51 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -96,20 +96,34 @@ enum ipu_channel_irq {
#define IPUV3_CHANNEL_CSI2 2
#define IPUV3_CHANNEL_CSI3 3
#define IPUV3_CHANNEL_VDI_MEM_IC_VF 5
+#define IPUV3_CHANNEL_MEM_VDI_PREV 8
+#define IPUV3_CHANNEL_MEM_VDI_CUR 9
+#define IPUV3_CHANNEL_MEM_VDI_NEXT 10
#define IPUV3_CHANNEL_MEM_IC_PP11
#define IPUV3_CHANNEL_MEM_IC_PRP_VF12
+#define IPUV3_CHANNEL_VDI_MEM_RECENT 13
#define IPUV3_CHANNEL_G_MEM_IC_PRP_VF 14
#define IPUV3_CHANNEL_G_MEM_IC_PP 15
+#define IPUV3_CHANNEL_G_MEM_IC_PRP_VF_ALPHA17
+#define IPUV3_CHANNEL_G_MEM_IC_PP_ALPHA18
+#define IPUV3_CHANNEL_MEM_VDI_PLANE1_COMB_ALPHA19
#define IPUV3_CHANNEL_IC_PRP_ENC_MEM 20
#define IPUV3_CHANNEL_IC_PRP_VF_MEM21
#define IPUV3_CHANNEL_IC_PP_MEM22
#define IPUV3_CHANNEL_MEM_BG_SYNC 23
#define IPUV3_CHANNEL_MEM_BG_ASYNC 24
+#define IPUV3_CHANNEL_MEM_VDI_PLANE1_COMB 25
+#define IPUV3_CHANNEL_MEM_VDI_PLANE3_COMB 26
#define IPUV3_CHANNEL_MEM_FG_SYNC 27
#define IPUV3_CHANNEL_MEM_DC_SYNC 28
#define IPUV3_CHANNEL_MEM_FG_ASYNC 29
#define IPUV3_CHANNEL_MEM_FG_SYNC_ALPHA31
+#define IPUV3_CHANNEL_MEM_FG_ASYNC_ALPHA 33
+#define IPUV3_CHANNEL_DC_MEM_READ 40
#define IPUV3_CHANNEL_MEM_DC_ASYNC 41
+#define IPUV3_CHANNEL_MEM_DC_COMMAND 42
+#define IPUV3_CHANNEL_MEM_DC_COMMAND2 43
+#define IPUV3_CHANNEL_MEM_DC_OUTPUT_MASK 44
#define IPUV3_CHANNEL_MEM_ROT_ENC 45
#define IPUV3_CHANNEL_MEM_ROT_VF 46
#define IPUV3_CHANNEL_MEM_ROT_PP 47
@@ -117,6 +131,7 @@ enum ipu_channel_irq {
#define IPUV3_CHANNEL_ROT_VF_MEM 49
#define IPUV3_CHANNEL_ROT_PP_MEM 50
#define IPUV3_CHANNEL_MEM_BG_SYNC_ALPHA51
+#define IPUV3_CHANNEL_MEM_BG_ASYNC_ALPHA 52
int ipu_map_irq(struct ipu_soc *ipu, int irq);
int ipu_idmac_channel_irq(struct ipu_soc *ipu, struct ipuv3_channel *channel,
--
2.1.4
[PATCH v3 0/5] i.MX5/6 mem2mem scaler
Hi,
this series uses the IPU IC post-processing task to implement
a mem2mem device for scaling and colorspace conversion. This
version addresses a few review commends, and includes some
further cleanup.
Changes since v2:
- Limit downscaling to 4:1
- Disabled USERPTR memory
- Set icc pointer to NULL on error
- Dropped currently unused IDMAC channels
- Fixed scaler module description
- Embedded struct video_device
If it is acceptable, I'd like to merge this through drm-next via imx-drm.
Mauro reportedly would be ok with that, and currently the potential for
conflicts is limited to drivers/media/{Kconfig,Makefile}. If not, I'll
postpone the two [media] patches for a release.
regards
Philipp
Philipp Zabel (3):
gpu: ipu-v3: Add missing IDMAC channel names
gpu: ipu-v3: Add mem2mem image conversion support to IC
gpu: ipu-v3: Register scaler platform device
Sascha Hauer (2):
[media] imx-ipu: Add ipu media common code
[media] imx-ipu: Add i.MX IPUv3 scaler driver
drivers/gpu/ipu-v3/ipu-common.c | 2 +
drivers/gpu/ipu-v3/ipu-ic.c | 754 +++-
drivers/media/platform/Kconfig | 2 +
drivers/media/platform/Makefile | 1 +
drivers/media/platform/imx/Kconfig | 11 +
drivers/media/platform/imx/Makefile | 2 +
drivers/media/platform/imx/imx-ipu-scaler.c | 859
drivers/media/platform/imx/imx-ipu.c| 313 ++
drivers/media/platform/imx/imx-ipu.h| 36 ++
include/video/imx-ipu-v3.h | 49 +-
10 files changed, 2012 insertions(+), 17 deletions(-)
create mode 100644 drivers/media/platform/imx/Kconfig
create mode 100644 drivers/media/platform/imx/Makefile
create mode 100644 drivers/media/platform/imx/imx-ipu-scaler.c
create mode 100644 drivers/media/platform/imx/imx-ipu.c
create mode 100644 drivers/media/platform/imx/imx-ipu.h
--
2.1.4
drm/edid: sound/core: pcm_drm_eld.c compilation error in 4.2
The file sound/core/pcm_drm_eld.c which was added by the commit 838d1631b766529213684f07dd71cdf2e92f0623 ALSA: pcm: add DRM ELD helper lacks the function drm_eld_sad() which was defined by Russell's patch http://article.gmane.org/gmane.linux.ports.arm.kernel/411574 drm/edid: add function to help find SADs This patch has not been applied. -- Ken ar c'hentañ| ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/
[PATCH 1/8] drm/bochs: phase 1 - use the transitional helpers
On Do, 2015-07-16 at 20:20 +0800, John Hunter wrote: > --- a/drivers/gpu/drm/bochs/bochs_kms.c > +++ b/drivers/gpu/drm/bochs/bochs_kms.c > @@ -10,6 +10,11 @@ > > static int defx = 1024; > static int defy = 768; > +static u64 gpu_addr = 0; That isn't going to fly. Guess you could it that into struct bochs_framebuffer. cheers, Gerd
drm/edid: sound/core: pcm_drm_eld.c compilation error in 4.2
On Thu, Jul 16, 2015 at 06:16:58PM +0200, Jean-Francois Moine wrote: > The file sound/core/pcm_drm_eld.c which was added by the commit > > 838d1631b766529213684f07dd71cdf2e92f0623 > ALSA: pcm: add DRM ELD helper > > lacks the function drm_eld_sad() which was defined by Russell's patch > > http://article.gmane.org/gmane.linux.ports.arm.kernel/411574 > drm/edid: add function to help find SADs > > This patch has not been applied. Grr, that's the danger of trying to split changes which cross between subsystems. I hate todays fragmented nature of kernel development, it's really a nightmare. I'm not sure how this can be resolved now, I asked Dave Airlie to pull the next set of patches which include the one adding the SAD helper; he's probably already pulled that for -next, so to pull out just that patch and try to get it merged into -rc is going to be far from nice, and will probably introduce conflicts. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net.
[PATCH] drm: sti: fix sub-components bind
hi ben: your patch is ok, i don't know your hardware how to use. In this first code why use that style dts? If you detail research our patch, you will find that it can compatiable your fixing dts. If you don't approve our patch better, I will be glad to see you to slove this bug Thank you Xinwei On 2015/7/15 21:34, Thierry Reding wrote: > On Wed, Jul 15, 2015 at 03:21:46PM +0200, Benjamin Gaignard wrote: >> Fix misunderstanding in how use component framework. >> drm_platform_init() is now call only when all the >> sub-components are register themselves instead of the >> previous two stages mechanism. >> >> Update devicetree and bindings documentation according >> to this new behavior. >> >> Signed-off-by: Benjamin Gaignard >> --- >> .../devicetree/bindings/gpu/st,stih4xx.txt | 7 +- >> arch/arm/boot/dts/stih407.dtsi | 82 >> +++--- >> arch/arm/boot/dts/stih410.dtsi | 82 >> +++--- >> drivers/gpu/drm/sti/sti_drm_drv.c | 45 ++-- >> drivers/gpu/drm/sti/sti_hdmi.c | 25 --- >> drivers/gpu/drm/sti/sti_tvout.c| 46 ++-- >> 6 files changed, 105 insertions(+), 182 deletions(-) > > Isn't this going to break DT ABI? How are you going to ensure backwards- > compatibility with old DTBs? > > Thierry >
[PATCH 1/1] drm/sti: fix master bind bug for using component
hi ben: your patch is ok, i don't know your hardware how to use. In this first code why use that style dts? If you detail research our patch, you will find that it can compatiable your fixing dts. If you don't approve our patch better, I will be glad to see you to slove this bug Thank you Xinwei On 2015/7/16 15:17, Benjamin Gaignard wrote: > This patch isn't the good one, I send the fix here: > http://lists.freedesktop.org/archives/dri-devel/2015-July/086568.html > > Regards, > Benjamin > > 2015-07-16 3:13 GMT+02:00 Xinwei Kong : >> Thank you for Russel. >> >> It is Right, when this sti_tvout (component) finish executing component >> ".bind" >> function while sti_hdmi or sti_hda is not registered. the bug will occur . >> >> this patch will prepare this bug by calling master .bind of sti_tvout after >> sti_hdmi or sti_hda is register to finish binding sti_hdmi or sti_hda >> component, >> however, it also slove to bring the "drm_dev" struct into the sti_hdmi or >> sti_hda. >> >> Thank you >> Xinwei >> >> On 2015/7/15 21:17, Benjamin Gaignard wrote: >>> Thanks a lot Russell, I have now understand where was my mistake. >>> >>> >>> 2015-07-15 12:42 GMT+02:00 Russell King - ARM Linux >> arm.linux.org.uk>: On Wed, Jul 15, 2015 at 12:19:01PM +0200, Benjamin Gaignard wrote: > The build order in Makefile hasn't been change so the bug doesn't occur... > > In addition of taking care of not changing build order in Makefile, > I would like to understand what is the expected behavior of component > framework when > master call component_bind_all() before any component_add() calls. > > Should component bind function be called in component_add() ? > Is up to component to detect that master is already bounded ? > > Russell can you tell us what to do in this case ? I don't follow, and you certainly should never get into the situation you're alluding to (where the master is already bound but a component is not.) The way this should work is: - master and components register themselves into the component helper in a random order. - when the master registers, it gives the component helper a set of matches which it uses to determine which components are required. - when the component helper determines that all components and the master have been registered, it calls the master bind function. - the master bind function is responsible for the classical subsystem initialisation, calling component_bind_all() to cause the individual components bind() method to be called. So, you should never _ever_ be in the situation where initcall ordering matters, or where the master is already bound but a component hasn't registered. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. >>> >>> >>> >> > > >
[pull] radeon and amdgpu drm-fixes-4.2
Hi Dave, More radeon and amdgpu fixes for 4.2. Mostly amdgpu bug fixes. The following changes since commit 3aa20508a6fe386c2a893027ef4c4ef78ee4eac2: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security (2015-07-15 18:38:24 -0700) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.2 for you to fetch changes up to 1002d71841d52b2390c82c2bc18922ac21fbd090: drm/amdgpu/dce8: Re-set VBLANK interrupt state when enabling a CRTC (2015-07-16 12:39:44 -0400) Alex Deucher (8): drm/radeon: add a dpm quirk for Sapphire Radeon R9 270X 2GB GDDR5 drm/amdgpu: disable the IP module if early_init returns -ENOENT (v2) drm/amdgpu: set proper index/data pair for smc regs on CZ (v2) drm/amdgpu: remove bogus check in gfx8 rb setup drm/amdgpu/cz: unforce dpm levels before forcing to low/high drm/amdgpu/cz: store the forced dpm level drm/amdgpu/cz: silence some dpm debug output drm/radeon/ci: silence a harmless PCC warning Christian König (3): drm/radeon: fix user ptr race condition drm/amdgpu: validate the context id in the dependencies drm/amdgpu: stop context leak in the error path Michel Dänzer (2): drm/radeon: Don't flush the GART TLB if rdev->gart.ptr == NULL drm/amdgpu/dce8: Re-set VBLANK interrupt state when enabling a CRTC drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 19 +--- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 ++-- drivers/gpu/drm/amd/amdgpu/cz_dpm.c| 16 ++ drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 4 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 5 + drivers/gpu/drm/amd/amdgpu/vi.c| 35 -- drivers/gpu/drm/radeon/ci_dpm.c| 2 +- drivers/gpu/drm/radeon/radeon_gart.c | 12 ++ drivers/gpu/drm/radeon/radeon_gem.c| 1 + drivers/gpu/drm/radeon/radeon_object.c | 1 - drivers/gpu/drm/radeon/si_dpm.c| 1 + 11 files changed, 84 insertions(+), 21 deletions(-)
[PATCH v1.1 01/13] drm/atomic: Only update crtc->x/y if it's part of the state, v2.
On Thu, Jul 16, 2015 at 03:51:01PM +0200, Maarten Lankhorst wrote:
> Universal planes may not be assigned to the current crtc, so only
> update crtc->x/y when the primary is part of the state and bound
> to the current crtc.
>
> Changes since v1:
> - Add the crtc check.
>
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Maarten Lankhorst
Applied to topic/drm-misc, thanks.
-Daniel
> ---
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index e52dfc828e60..9ede58365ae1 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -665,10 +665,16 @@ drm_atomic_helper_update_legacy_modeset_state(struct
> drm_device *dev,
>
> /* set legacy state in the crtc structure */
> for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> + struct drm_plane *primary = crtc->primary;
> +
> crtc->mode = crtc->state->mode;
> crtc->enabled = crtc->state->enable;
> - crtc->x = crtc->primary->state->src_x >> 16;
> - crtc->y = crtc->primary->state->src_y >> 16;
> +
> + if (drm_atomic_get_existing_plane_state(old_state, primary) &&
> + primary->state->crtc == crtc) {
> + crtc->x = primary->state->src_x >> 16;
> + crtc->y = primary->state->src_y >> 16;
> + }
>
> if (crtc->state->enable)
> drm_calc_timestamping_constants(crtc,
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH libdrm] man: remove .man_fixup workaround
The whole thing is quite messy - the file is used to indicate that the man pages were correctly generated prior to applying the "fixup" (alias) At the same time we use a rule with the same name, to create the same file if the generation has failed. In other words - it attempts to create the file either way. So there is little point in it and we can remove it. Spotted while attempting to build with bmake which kindly blocked on the following (non compliant construct) .man_fixup: | $(miscman_DATA) Cc: Jonathan Gray Signed-off-by: Emil Velikov --- Jonathan, With the following patch libdrm build fine on my Arch + bmake. The `dist' target is still broken, yet `all' and `check' work great. Will you guys consider moving back to the upstream build ? As mentioned before if there are problems do mention/file bugs so that we can get them sorted. -Emil man/Makefile.am | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/man/Makefile.am b/man/Makefile.am index 44b63a5..00eb423 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -37,7 +37,7 @@ MAN_FILES = \ $(miscman_aliases_DATA) EXTRA_DIST = $(XML_FILES) -CLEANFILES = $(MAN_FILES) .man_fixup +CLEANFILES = $(MAN_FILES) XSLTPROC_FLAGS = \ --stringparam man.authors.section.enabled 0 \ @@ -48,14 +48,9 @@ XSLTPROC_FLAGS = \ $(MANPAGES_STYLESHEET) XSLTPROC_PROCESS_MAN = \ - $(AM_V_GEN)$(XSLTPROC) -o "$@" $(XSLTPROC_FLAGS) "$<" && \ - touch .man_fixup + $(AM_V_GEN)$(XSLTPROC) -o "$@" $(XSLTPROC_FLAGS) "$<" -# Force .man_fixup if $(miscman_DATA) are not built -.man_fixup: | $(miscman_DATA) - $(AM_V_GEN)touch .man_fixup - -$(miscman_aliases_DATA): $(miscman_DATA) .man_fixup +$(miscman_aliases_DATA): $(miscman_DATA) $(AM_V_GEN)if test -n "$@" ; then $(SED) -i -e 's/^\.so \([a-z_]\+\)\.\([0-9]\)$$/\.so man\2\/\1\.\2/' "$@" ; fi SUFFIXES = .$(LIB_MAN_SUFFIX) .$(MISC_MAN_SUFFIX) .xml -- 2.4.5
[PATCH libdrm 3/4] xf86drm: fix incorrect fd comparison in drmOpenOnce{, WithType}
On 15 July 2015 at 13:47, Thierry Reding wrote: > On Wed, Jul 15, 2015 at 01:37:22PM +0100, Emil Velikov wrote: >> On 15 July 2015 at 12:47, Thierry Reding wrote: >> > On Tue, Jul 14, 2015 at 03:10:04PM +0100, Emil Velikov wrote: >> >> Spotted by looking for similar "let's assume fd == 0 is invalid" bugs. >> >> >> >> Cc: Thierry Reding >> >> Signed-off-by: Emil Velikov >> >> --- >> >> xf86drm.c | 2 +- >> >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> >> >> diff --git a/xf86drm.c b/xf86drm.c >> >> index 2c17d11..39c6e2d 100644 >> >> --- a/xf86drm.c >> >> +++ b/xf86drm.c >> >> @@ -2619,7 +2619,7 @@ int drmOpenOnceWithType(const char *BusID, int >> >> *newlyopened, int type) >> >> } >> >> >> >> fd = drmOpenWithType(NULL, BusID, type); >> >> -if (fd <= 0 || nr_fds == DRM_MAX_FDS) >> >> +if (fd < 0 || nr_fds == DRM_MAX_FDS) >> > >> > Consider what happens if we have DRM_MAX_FDS file descriptors open and >> > the call to drmOpenWithType() succeeds. We'll end up returning the file >> > descriptor as is, but we won't keep track. >> > >> > I suppose this could have been on purpose, so that the device could be >> > opened even if the file descriptor couldn't be cached anymore. One >> > potential problem with that could be that the open-once restriction >> > would be silently ignored. That may not be desirable. >> > >> Thanks for reviewing ! >> >> Yes I have considered the issue. It's slightly different bug (fixed by >> using dynamic allocation?) than what this patch aims at. This fix came >> along for consistency sake rather than me caring about this legacy >> API. > > Right, I had meant to say: > > Reviewed-by: Thierry Reding > > irrespective of the above, given that they are two orthogonal issues. > Ack. Greatly appreciated. -Emil
[PATCH] drm/fbdev: Return -EBUSY when oopsing
Trying to do anything with kms drivers when oopsing has become a
failing proposition. But since we can end up in the fbdev code simply
due to the console unblanking that's done unconditionally just
removing our panic handler isn't enough. We need to block all fbdev
callbacks when oopsing.
There was already one in the blank handler, but it failed silently.
That makes it impossible for drivers (like i915) who subclass these
functions to figure this out.
Instead consistently return -EBUSY so that everyone knows that we
really don't want to be bothered right now. This also allows us to
remove a pile of FIXMEs from the i915 fbdev code (since due to the
failure code they now won't attempt to grab dangerous locks any more).
Cc: Dave Airlie
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c| 24
drivers/gpu/drm/i915/intel_fbdev.c | 21 -
2 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 329d08167b77..22056d0807bb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -509,14 +509,6 @@ static void drm_fb_helper_dpms(struct fb_info *info, int
dpms_mode)
int i, j;
/*
-* fbdev->blank can be called from irq context in case of a panic.
-* Since we already have our own special panic handler which will
-* restore the fbdev console mode completely, just bail out early.
-*/
- if (oops_in_progress)
- return;
-
- /*
* For each CRTC in this fb, turn the connectors on/off.
*/
drm_modeset_lock_all(dev);
@@ -549,6 +541,9 @@ static void drm_fb_helper_dpms(struct fb_info *info, int
dpms_mode)
*/
int drm_fb_helper_blank(int blank, struct fb_info *info)
{
+ if (oops_in_progress)
+ return -EBUSY;
+
switch (blank) {
/* Display: On; HSync: On, VSync: On */
case FB_BLANK_UNBLANK:
@@ -776,9 +771,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct
fb_info *info)
int i, j, rc = 0;
int start;
- if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
+ if (oops_in_progress)
return -EBUSY;
- }
+
+ drm_modeset_lock_all(dev);
if (!drm_fb_helper_is_bound(fb_helper)) {
drm_modeset_unlock_all(dev);
return -EBUSY;
@@ -927,6 +923,9 @@ int drm_fb_helper_set_par(struct fb_info *info)
struct drm_fb_helper *fb_helper = info->par;
struct fb_var_screeninfo *var = &info->var;
+ if (oops_in_progress)
+ return -EBUSY;
+
if (var->pixclock != 0) {
DRM_ERROR("PIXEL CLOCK SET\n");
return -EINVAL;
@@ -952,9 +951,10 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
*var,
int ret = 0;
int i;
- if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
+ if (oops_in_progress)
return -EBUSY;
- }
+
+ drm_modeset_lock_all(dev);
if (!drm_fb_helper_is_bound(fb_helper)) {
drm_modeset_unlock_all(dev);
return -EBUSY;
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index eef54feb7545..b763f24e20ef 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -55,13 +55,6 @@ static int intel_fbdev_set_par(struct fb_info *info)
ret = drm_fb_helper_set_par(info);
if (ret == 0) {
- /*
-* FIXME: fbdev presumes that all callbacks also work from
-* atomic contexts and relies on that for emergency oops
-* printing. KMS totally doesn't do that and the locking here is
-* by far not the only place this goes wrong. Ignore this for
-* now until we solve this for real.
-*/
mutex_lock(&fb_helper->dev->struct_mutex);
intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
mutex_unlock(&fb_helper->dev->struct_mutex);
@@ -80,13 +73,6 @@ static int intel_fbdev_blank(int blank, struct fb_info *info)
ret = drm_fb_helper_blank(blank, info);
if (ret == 0) {
- /*
-* FIXME: fbdev presumes that all callbacks also work from
-* atomic contexts and relies on that for emergency oops
-* printing. KMS totally doesn't do that and the locking here is
-* by far not the only place this goes wrong. Ignore this for
-* now until we solve this for real.
-*/
mutex_lock(&fb_helper->dev->struct_mutex);
intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
mutex_unlock(&fb_helper->dev->struct_mutex);
@@ -106,13 +92,6 @@ static int intel_fbdev_pan_display(struct fb_var_screeninfo
[PATCH 2/2] drm/i915: Don't reprobe on resume
If we don't force the connector state to unknown there's no reason any more to force a reprobe. Also no other driver bothers with this, so probably it's not required - userspace handles lid/resume events through other channels already. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/i915_drv.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 6f6fdb44e17a..8e86da63cf5d 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -733,8 +733,6 @@ static int i915_drm_resume(struct drm_device *dev) * notifications. * */ intel_hpd_init(dev_priv); - /* Config may have changed between suspend and resume */ - drm_helper_hpd_irq_event(dev); intel_opregion_init(dev); -- 2.1.4
[PATCH 1/2] drm: Stop resetting connector state to unknown
It's causing piles of issues since we've stopped forcing full detect
cycles in the sysfs interfaces with
commit c484f02d0f02fbbfc6decc945a69aae011041a27
Author: Chris Wilson
Date: Fri Mar 6 12:36:42 2015 +
drm: Lighten sysfs connector 'status'
The original justification for this was that the hpd handlers could
use the unknown state as a hint to force a full detection. But current
i915 code isn't doing that any more, and no one else really uses reset
on resume. So instead just keep the old state around.
References:
http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/62584
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=100641
Cc: Rui Matos
Cc: Julien Wajsberg
Cc: kuddel.mail at gmx.de
Cc: Lennart Poettering
Cc: stable at vger.kernel.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_crtc.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 1f0da41ae2a1..c91c18b2b1d4 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -5273,12 +5273,9 @@ void drm_mode_config_reset(struct drm_device *dev)
if (encoder->funcs->reset)
encoder->funcs->reset(encoder);
- drm_for_each_connector(connector, dev) {
- connector->status = connector_status_unknown;
-
+ drm_for_each_connector(connector, dev)
if (connector->funcs->reset)
connector->funcs->reset(connector);
- }
}
EXPORT_SYMBOL(drm_mode_config_reset);
--
2.1.4
[alsa-devel] [PATCH 1/2] V4 regmap: Use reg_sequence for multi_reg_write / register_patch
On Thu, Jul 16, 2015 at 01:52:54PM +0100, Mark Brown wrote:
> On Tue, Jul 14, 2015 at 03:45:51PM +0100, Nariman Poushin wrote:
>
> Please submit patches in the format covered in SubmittingPatches,
> version information goes inside the [].
>
> > Add support for writing sequences of registers / patches with specified
> > delays (in microseconds). Logically separates the functionality using
> > sequences of register writes from the functions that take register
> > defaults, as adding a delay field on the reg_defaults can increase
> > memory usage substantially.
>
> This change doesn't do what the above changelog says. It introduces a
> new struct reg_sequence and updates the multi write and patch APIs to
> use that but it doesn't implement any delay functionality. Please
> resend with a clearer changelog that describes why the struct is being
> split out from the reg_defaults struct and makes it clear that this is
> just a rename. It's probably best to also defer the addition of the
> delay field until the second patch where this function is actually
> implemented.
>
> > +/**
> > + * Register / Value pairs for sequences of writes, incorporating an
> > optional
>
> Register/value.
>
> > + * delay in microseconds.
> > + *
> > + * @reg: Register address.
> > + * @def: Register default value.
> > + * @delay_us: Delay in microseconds
> > + */
> > +
> > +struct reg_sequence {
>
> No blank line between the kerneldoc and the struct (as is the style for
> other kernel code).
I realized that I resent my patches with out outlining the changes from
the previous patch set (V5 vs V4), not sure if it is best to resend
with a cover letter (which would increase noise)?
Anyway, I addressed your both your and Takashi's comments, thanks both
for your feedback.
I will resend with a cover letter explaining the change from the previous
patch set if that is the right thing to do.
Thanks
Nariman
> ___
> Alsa-devel mailing list
> Alsa-devel at alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
[PATCH 2/2 V5] regmap: Apply optional delay in multi_reg_write/register_patch
Add an optional delay_us field in reg_sequence to allow the client to
specify a delay (in microseconds) to be applied after any given write
in a sequence of writes.
We treat a delay in a sequence the same way we treat a page change as
they are logically similar in that you can coalesce all write before
a delay (in the same way you can coalesce all writes before a page
change is needed)
Signed-off-by: Nariman Poushin
---
drivers/base/regmap/regmap.c | 54 +++-
include/linux/regmap.h | 5 +++-
2 files changed, 52 insertions(+), 7 deletions(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 0a849ee..fd4dac9 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include "trace.h"
@@ -1819,10 +1820,12 @@ static int _regmap_range_multi_paged_reg_write(struct
regmap *map,
int i, n;
struct reg_sequence *base;
unsigned int this_page = 0;
+ unsigned int page_change = 0;
/*
* the set of registers are not neccessarily in order, but
* since the order of write must be preserved this algorithm
-* chops the set each time the page changes
+* chops the set each time the page changes. This also applies
+* if there is a delay required at any point in the sequence.
*/
base = regs;
for (i = 0, n = 0; i < num_regs; i++, n++) {
@@ -1838,16 +1841,48 @@ static int _regmap_range_multi_paged_reg_write(struct
regmap *map,
this_page = win_page;
if (win_page != this_page) {
this_page = win_page;
+ page_change = 1;
+ }
+ }
+
+ /* If we have both a page change and a delay make sure to
+* write the regs and apply the delay before we change the
+* page.
+*/
+
+ if (page_change || regs[i].delay_us) {
+
+ /* For situations where the first write requires
+* a delay we need to make sure we don't call
+* raw_multi_reg_write with n=0
+* This can't occur with page breaks as we
+* never write on the first iteration
+*/
+ if (regs[i].delay_us && i == 0)
+ n = 1;
+
ret = _regmap_raw_multi_reg_write(map, base, n);
if (ret != 0)
return ret;
+
+ if (regs[i].delay_us)
+ udelay(regs[i].delay_us);
+
base += n;
n = 0;
- }
- ret = _regmap_select_page(map, &base[n].reg, range, 1);
- if (ret != 0)
- return ret;
+
+ if (page_change) {
+ ret = _regmap_select_page(map,
+ &base[n].reg,
+ range, 1);
+ if (ret != 0)
+ return ret;
+
+ page_change = 0;
+ }
+
}
+
}
if (n > 0)
return _regmap_raw_multi_reg_write(map, base, n);
@@ -1866,6 +1901,9 @@ static int _regmap_multi_reg_write(struct regmap *map,
ret = _regmap_write(map, regs[i].reg, regs[i].def);
if (ret != 0)
return ret;
+
+ if (regs[i].delay_us)
+ udelay(regs[i].delay_us);
}
return 0;
}
@@ -1905,8 +1943,12 @@ static int _regmap_multi_reg_write(struct regmap *map,
for (i = 0; i < num_regs; i++) {
unsigned int reg = regs[i].reg;
struct regmap_range_node *range;
+
+ /* Coalesce all the writes between a page break or a delay
+* in a sequence
+*/
range = _regmap_range_lookup(map, reg);
- if (range) {
+ if (range || regs[i].delay_us) {
size_t len = sizeof(struct reg_sequence)*num_regs;
struct reg_sequence *base = kmemdup(regs, len,
GFP_KERNEL);
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index 4a67590..e32c2
[PATCH 1/2 V5] regmap: Use reg_sequence for multi_reg_write / register_patch
Separate the functionality using sequences of register writes from the
functions that take register defaults. This change renames the arguments
in order to support the extension of reg_sequence to take an optional
delay to be applied after any given register in a sequence is written.
This avoids adding an int to all register defaults, which could
substantially increase memory usage for regmaps with large default tables.
This also updates all the clients of multi_reg_write/register_patch.
Signed-off-by: Nariman Poushin
---
drivers/base/regmap/internal.h | 2 +-
drivers/base/regmap/regmap.c | 22 +++---
drivers/gpu/drm/i2c/adv7511.c | 2 +-
drivers/input/misc/drv260x.c | 6 +++---
drivers/input/misc/drv2665.c | 2 +-
drivers/input/misc/drv2667.c | 4 ++--
drivers/mfd/arizona-core.c | 2 +-
drivers/mfd/twl6040.c | 2 +-
drivers/mfd/wm5102-tables.c| 6 +++---
drivers/mfd/wm5110-tables.c| 6 +++---
drivers/mfd/wm8994-core.c | 8
drivers/mfd/wm8997-tables.c| 2 +-
include/linux/regmap.h | 17 ++---
sound/soc/codecs/arizona.c | 2 +-
sound/soc/codecs/cs35l32.c | 2 +-
sound/soc/codecs/cs42l52.c | 2 +-
sound/soc/codecs/da7210.c | 4 ++--
sound/soc/codecs/rt5640.c | 2 +-
sound/soc/codecs/rt5645.c | 4 ++--
sound/soc/codecs/rt5651.c | 2 +-
sound/soc/codecs/rt5670.c | 2 +-
sound/soc/codecs/rt5677.c | 2 +-
sound/soc/codecs/tlv320aic3x.c | 2 +-
sound/soc/codecs/wm2200.c | 2 +-
sound/soc/codecs/wm5100.c | 2 +-
sound/soc/codecs/wm8962.c | 2 +-
sound/soc/codecs/wm8993.c | 2 +-
27 files changed, 62 insertions(+), 51 deletions(-)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index b2b2849..873ddf9 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -136,7 +136,7 @@ struct regmap {
/* if set, the HW registers are known to match map->reg_defaults */
bool no_sync_defaults;
- struct reg_default *patch;
+ struct reg_sequence *patch;
int patch_regs;
/* if set, converts bulk rw to single rw */
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index dd63bcb..0a849ee 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -1755,7 +1755,7 @@ EXPORT_SYMBOL_GPL(regmap_bulk_write);
* relative. The page register has been written if that was neccessary.
*/
static int _regmap_raw_multi_reg_write(struct regmap *map,
- const struct reg_default *regs,
+ const struct reg_sequence *regs,
size_t num_regs)
{
int ret;
@@ -1812,12 +1812,12 @@ static unsigned int _regmap_register_page(struct regmap
*map,
}
static int _regmap_range_multi_paged_reg_write(struct regmap *map,
- struct reg_default *regs,
+ struct reg_sequence *regs,
size_t num_regs)
{
int ret;
int i, n;
- struct reg_default *base;
+ struct reg_sequence *base;
unsigned int this_page = 0;
/*
* the set of registers are not neccessarily in order, but
@@ -1855,7 +1855,7 @@ static int _regmap_range_multi_paged_reg_write(struct
regmap *map,
}
static int _regmap_multi_reg_write(struct regmap *map,
- const struct reg_default *regs,
+ const struct reg_sequence *regs,
size_t num_regs)
{
int i;
@@ -1907,8 +1907,8 @@ static int _regmap_multi_reg_write(struct regmap *map,
struct regmap_range_node *range;
range = _regmap_range_lookup(map, reg);
if (range) {
- size_t len = sizeof(struct reg_default)*num_regs;
- struct reg_default *base = kmemdup(regs, len,
+ size_t len = sizeof(struct reg_sequence)*num_regs;
+ struct reg_sequence *base = kmemdup(regs, len,
GFP_KERNEL);
if (!base)
return -ENOMEM;
@@ -1941,7 +1941,7 @@ static int _regmap_multi_reg_write(struct regmap *map,
* A value of zero will be returned on success, a negative errno will be
* returned in error cases.
*/
-int regmap_multi_reg_write(struct regmap *map, const struct reg_default *regs,
+int regmap_multi_reg_write(struct regmap *map, const struct reg_sequence *regs,
int num_regs)
{
int ret;
@@ -1974,7 +1974,7 @@ EXPORT_SYMBOL_GPL(regmap_multi_reg_write);
* be returned in error cases.
*/
int regmap_multi_reg_write_bypassed(struct regmap *map,
- const st
[PATCH 2/2] drm/i915: Don't reprobe on resume
On Thu, Jul 16, 2015 at 04:47:51PM +0200, Daniel Vetter wrote: > If we don't force the connector state to unknown there's no reason any > more to force a reprobe. Also no other driver bothers with this, so > probably it's not required - userspace handles lid/resume events > through other channels already. No, we don't. We don't synthesize any events at all for changing connectors whilst suspended and userspace doesn't know about being suspended. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[Bug 91268] R6xx freezes with kernel 3.17 and up
https://bugs.freedesktop.org/show_bug.cgi?id=91268 --- Comment #17 from Kajzer --- (In reply to Alex Deucher from comment #16) > (In reply to Kajzer from comment #15) > > (In reply to Alex Deucher from comment #14) > > > Do you see this bug if you don't enable dpm at all (which is the default)? > > > > Ah I get you now... I don't know, there's no point for me to even be on > > Linux without dpm, but if you think that testing that would solve some > > things then I guess I can try that. I'll let you know. > > Yes, please test. I just did and it happened fast, 20 mins after game started. So, answer is yes, I see this bug when dpm is disabled. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/16395dd8/attachment.html>
[PATCH v1.1 2/5] drm/atomic: Make prepare_fb/cleanup_fb only take state, v2.
This removes the need to separately track fb changes i915.
Changes since v1:
- Add dri-devel to cc.
- Fix a check in intel's prepare and cleanup fb to take rotation
into account.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index be9fa8220499..36fda86b3518 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -712,11 +712,13 @@ static int atmel_hlcdc_plane_atomic_check(struct
drm_plane *p,
}
static int atmel_hlcdc_plane_prepare_fb(struct drm_plane *p,
- struct drm_framebuffer *fb,
const struct drm_plane_state *new_state)
{
struct atmel_hlcdc_plane *plane = drm_plane_to_atmel_hlcdc_plane(p);
+ if (!new_state->fb)
+ return 0;
+
return atmel_hlcdc_layer_update_start(&plane->layer);
}
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 0898afbc9e23..e52dfc828e60 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1063,17 +1063,14 @@ int drm_atomic_helper_prepare_planes(struct drm_device
*dev,
const struct drm_plane_helper_funcs *funcs;
struct drm_plane *plane = state->planes[i];
struct drm_plane_state *plane_state = state->plane_states[i];
- struct drm_framebuffer *fb;
if (!plane)
continue;
funcs = plane->helper_private;
- fb = plane_state->fb;
-
- if (fb && funcs->prepare_fb) {
- ret = funcs->prepare_fb(plane, fb, plane_state);
+ if (funcs->prepare_fb) {
+ ret = funcs->prepare_fb(plane, plane_state);
if (ret)
goto fail;
}
@@ -1086,17 +1083,14 @@ fail:
const struct drm_plane_helper_funcs *funcs;
struct drm_plane *plane = state->planes[i];
struct drm_plane_state *plane_state = state->plane_states[i];
- struct drm_framebuffer *fb;
if (!plane)
continue;
funcs = plane->helper_private;
- fb = state->plane_states[i]->fb;
-
- if (fb && funcs->cleanup_fb)
- funcs->cleanup_fb(plane, fb, plane_state);
+ if (funcs->cleanup_fb)
+ funcs->cleanup_fb(plane, plane_state);
}
@@ -1252,14 +1246,11 @@ void drm_atomic_helper_cleanup_planes(struct drm_device
*dev,
for_each_plane_in_state(old_state, plane, plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
- struct drm_framebuffer *old_fb;
funcs = plane->helper_private;
- old_fb = plane_state->fb;
-
- if (old_fb && funcs->cleanup_fb)
- funcs->cleanup_fb(plane, old_fb, plane_state);
+ if (funcs->cleanup_fb)
+ funcs->cleanup_fb(plane, plane_state);
}
}
EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index b07a213f5655..03b7afe455e6 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -425,7 +425,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
if (plane_funcs->prepare_fb && plane_state->fb &&
plane_state->fb != old_fb) {
- ret = plane_funcs->prepare_fb(plane, plane_state->fb,
+ ret = plane_funcs->prepare_fb(plane,
plane_state);
if (ret)
goto out;
@@ -478,8 +478,8 @@ int drm_plane_helper_commit(struct drm_plane *plane,
ret = 0;
}
- if (plane_funcs->cleanup_fb && old_fb)
- plane_funcs->cleanup_fb(plane, old_fb, plane_state);
+ if (plane_funcs->cleanup_fb)
+ plane_funcs->cleanup_fb(plane, plane_state);
out:
if (plane_state) {
if (plane->funcs->atomic_destroy_state)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7dbfeacf0f38..b3990264e137 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4775,17 +4775,6 @@ static void intel_pre_plane_update(struct intel_crtc
*crtc)
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
- struct drm_plane *p;
-
- /* Track fb's for any planes being disabled */
- drm_for_each_plane_mask(p, dev, atomic->disabled_pl
[PATCH v1.1 01/13] drm/atomic: Only update crtc->x/y if it's part of the state, v2.
Universal planes may not be assigned to the current crtc, so only
update crtc->x/y when the primary is part of the state and bound
to the current crtc.
Changes since v1:
- Add the crtc check.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index e52dfc828e60..9ede58365ae1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -665,10 +665,16 @@ drm_atomic_helper_update_legacy_modeset_state(struct
drm_device *dev,
/* set legacy state in the crtc structure */
for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
+ struct drm_plane *primary = crtc->primary;
+
crtc->mode = crtc->state->mode;
crtc->enabled = crtc->state->enable;
- crtc->x = crtc->primary->state->src_x >> 16;
- crtc->y = crtc->primary->state->src_y >> 16;
+
+ if (drm_atomic_get_existing_plane_state(old_state, primary) &&
+ primary->state->crtc == crtc) {
+ crtc->x = primary->state->src_x >> 16;
+ crtc->y = primary->state->src_y >> 16;
+ }
if (crtc->state->enable)
drm_calc_timestamping_constants(crtc,
[PATCH 01/13] drm/atomic: Only update crtc->x/y if it's part of the state.
Op 16-07-15 om 14:34 schreef Daniel Vetter:
> On Thu, Jul 16, 2015 at 11:38:18AM +0200, Maarten Lankhorst wrote:
>> Op 16-07-15 om 11:29 schreef Daniel Vetter:
>>> On Thu, Jul 16, 2015 at 11:17:29AM +0200, Maarten Lankhorst wrote:
Op 16-07-15 om 11:19 schreef Daniel Vetter:
> On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst wrote:
>> Cc: dri-devel at lists.freedesktop.org
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/drm_atomic_helper.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 0898afbc9e23..70e69904291d 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -667,8 +667,11 @@
>> drm_atomic_helper_update_legacy_modeset_state(struct drm_device *dev,
>> for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
>> crtc->mode = crtc->state->mode;
>> crtc->enabled = crtc->state->enable;
>> -crtc->x = crtc->primary->state->src_x >> 16;
>> -crtc->y = crtc->primary->state->src_y >> 16;
>> +
>> +if (drm_atomic_get_existing_plane_state(old_state,
>> crtc->primary)) {
>> +crtc->x = crtc->primary->state->src_x >> 16;
>> +crtc->y = crtc->primary->state->src_y >> 16;
>> +}
> What's the benefit here of only updating when something changed? The
> atomic state should be the master source so copying a few too many times
> shouldn't matter really.
Because you might not be holding plane lock, so primary->state may be
garbage.
>>> Anyone who wants to touch primary plane must grab the crtc lock, so crtc
>>> lock would give you an implicit read lock. At least that's been my
>>> thinking, but it could be that the primary plane is used on some other
>>> crtc, and then this is indeed garbage.
>> This is only true if the plane is active. If there is none you can still
>> update properties and
>> swap the plane state without locking the crtc.
> Ah right, so still possible to chase a being-freed primary->state pointer.
>
>>> So maybe we need even more checks than what you propose:
>>>
>>> if (drm_atomic_get_existing_plane_state(old_state, crtc->primary) &&
>>> crtc->primary->state->crtc == crtc) {
>>> crtc->x = crtc->primary->state->src_x >> 16;
>>> crtc->y = crtc->primary->state->src_y >> 16;
>>> }
>>>
>>> I think a comment explaining this would help (or at least in the commit
>>> message!).
>> But the primary and cursor planes are not allowed to move between crtc's?
> They are allowed to do that actually. crtc->primary and crtc->cursor is
> only really a hint to implement backwards compatibility. If you have
> generic plane hw with 2 crtc and planes can be freely assigned it would be
> silly to artificially restrict the backwards compat planes to 1 crtc.
> Otherwise we'd force 2 planes to be unusable when there's no external
> screen plugged in, defeating a lot of the value of making planes freely
> assignable.
Ok, in that case your change looks reasonable. I'll respin.
[Nouveau] CUDA fixed VA allocations and sparse mappings
On Tue, Jul 14, 2015 at 3:45 AM, Andrew Chew wrote: > I apologize for my ignorance. In digging through nouveau, I've become > a bit confused regarding the relationship between virtual address > allocations and nouveau bo's. > > From my reading of the code, it seems that a nouveau_bo really > encapsulates a buffer (whether imported, or allocated within nouveau like, > say, pushbuffers). So I'm confused about an earlier statement that to > allocate a chunk of address space, I have to create a nouveau_bo for it. It is the case right now because there is no mean for user-space to manipulate the GPU address space without having a nouveau_bo. So both are closely related. But if you implement the address space reservation ioctl, a nouveau_bo will not be required until you want to back that space with actual memory. > What I really want to do is reserve some space in the address allocator > (the stuff in nvkm/subdev/mmu/base.c). Note that there are no buffers > at this time. This is just blocking out some chunk of the address space > so that normal address space allocations (for, say, bo's) avoid this region. > > At some point after that, I'd like to import a buffer, and map it to > certain regions of my pre-allocated address space. This is why I can't > go through the normal path of importing a buffer...that path assumes there > is no address for this buffer, and tries to allocate one. In our case, > we already have an address in mind. Naively, at this point, I'd like to > create a nouveau_bo for this imported buffer, but not have it go through > the address allocator and instead just take a fixed address. I think our main issue is that (someone correct me if I am wrong) Nouveau will automatically create a GPU mapping when a buffer is imported through PRIME. If we can (1) prevent this from happening (or, less ideally, re-map the imported buffer afterwards), and (2) perform the mapping by ourselves, we should be good. For the sake of completeness, we should also solve that same issue for buffers created using the NOUVEAU_GEM_NEW ioctl. I am not sure how we can make (1) happen. Surely we cannot change the semantics of DRM_IOCTL_PRIME_FD_TO_HANDLE without breaking user-space. But maybe we can delay that automatic mapping, and only make it happen if no manual mapping has been performed in-between? This would leave us a window right after the object is imported to decide its GPU address, which is precisely what we need. For objects created using NOUVEAU_GEM_NEW, things might be as simple as adding a "do not map yet" flag. Regarding (2), I kind of feel like this is related to another issue we were having with imported buffers: that we have no way to specify their tiling options, contrary to buffers created with NOUVEAU_GEM_NEW. I had a pretty lame attempt at fixing this last point (http://lists.freedesktop.org/archives/dri-devel/2015-May/083052.html ), but it has been rejected, and probably for the best now that I think of it. Tiling and offset inside the GPU VM are both properties of a buffer, so why not handle them both using the same ioctl? We currently have DRM_NOUVEAU_GEM_INFO, which returns all these properties to user-space (see struct drm_nouveau_gem_info). How about introducing DRM_NOUVEAU_GEM_SET_INFO that would allow to change these properties, i.e. to change the tiling flags (which the tiling ioctl attempted to do), but also the mapping address if it is specified and valid? So in order to import a buffer at a fixed GPU address, after reserving a portion of the GPU VM for that purpose, one would: 1) use DRM_IOCTL_PRIME_FD_TO_HANDLE to import the buffer 2) invoke DRM_NOUVEAU_GEM_SET_INFO to map (or re-map if 1) already created a mapping) the buffer to the right address I suspect this proposal is full of flaws though, so feel free to shoot it down. :)
[alsa-devel] [PATCH 2/2] V4 regmap: Apply optional delay in multi_reg_write/register_patch
On Tue, 14 Jul 2015 16:45:52 +0200,
Nariman Poushin wrote:
>
> We treat a delay in a sequence the same way we treat a page change as
> they are logically similar in that you can coalesce all write before
> a delay (in the same way you can coalesce all writes before a page
> change is needed)
>
> Signed-off-by: Nariman Poushin
> ---
> drivers/base/regmap/regmap.c | 65
>
> 1 file changed, 59 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
> index 0a849ee..a67473c2 100644
> --- a/drivers/base/regmap/regmap.c
> +++ b/drivers/base/regmap/regmap.c
> @@ -18,6 +18,7 @@
> #include
> #include
> #include
> +#include
>
> #define CREATE_TRACE_POINTS
> #include "trace.h"
> @@ -47,6 +48,17 @@ static int _regmap_bus_reg_write(void *context, unsigned
> int reg,
> static int _regmap_bus_raw_write(void *context, unsigned int reg,
>unsigned int val);
>
> +static void regmap_sequence_delay(unsigned int delay_us)
> +{
> + /* For small delays it isn't worth setting up the hrtimers
> + * so fall back on udelay
> + */
> + if (delay_us < 10)
> + udelay(delay_us);
> + else
> + usleep_range(delay_us, delay_us * 2);
> +}
I think usleep_range() can't be used for fast_io, which is performed
inside a spinlock. And, the locking can't be known explicitly,
e.g. the caller may set its own config->lock, so even the check for
fast_io isn't enough.
Takashi
[PATCHv7 14/15] cec: s5p-cec: Add s5p-cec driver
Marek, Kamil,
On 06/29/15 12:14, Hans Verkuil wrote:
> From: Kamil Debski
>
> Add CEC interface driver present in the Samsung Exynos range of
> SoCs.
>
> The following files were based on work by SangPil Moon:
> - exynos_hdmi_cec.h
> - exynos_hdmi_cecctl.c
>
> Signed-off-by: Kamil Debski
> Signed-off-by: Hans Verkuil
> ---
> diff --git a/drivers/media/platform/s5p-cec/s5p_cec.c
> b/drivers/media/platform/s5p-cec/s5p_cec.c
> new file mode 100644
> index 000..0f16d00
> --- /dev/null
> +++ b/drivers/media/platform/s5p-cec/s5p_cec.c
> @@ -0,0 +1,283 @@
> +/* drivers/media/platform/s5p-cec/s5p_cec.c
> + *
> + * Samsung S5P CEC driver
> + *
> + * Copyright (c) 2014 Samsung Electronics Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This driver is based on the "cec interface driver for exynos soc" by
> + * SangPil Moon.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "exynos_hdmi_cec.h"
> +#include "regs-cec.h"
> +#include "s5p_cec.h"
> +
> +#define CEC_NAME "s5p-cec"
> +
> +static int debug;
> +module_param(debug, int, 0644);
> +MODULE_PARM_DESC(debug, "debug level (0-2)");
> +
> +static int s5p_cec_enable(struct cec_adapter *adap, bool enable)
> +{
> + struct s5p_cec_dev *cec = container_of(adap, struct s5p_cec_dev, adap);
> + int ret;
> +
> + if (enable) {
> + ret = pm_runtime_get_sync(cec->dev);
> +
> + adap->phys_addr = 0x100b;
This is a bogus physical address. The actual physical address has to be derived
from the EDID that is read by the HDMI transmitter.
I think in the case of this driver it will have to be userspace that assigns
the physical address after reading the EDID from drm/kms?
How did you test this, Kamil?
Regards,
Hans
> + s5p_cec_reset(cec);
> +
> + s5p_cec_set_divider(cec);
> + s5p_cec_threshold(cec);
> +
> + s5p_cec_unmask_tx_interrupts(cec);
> + s5p_cec_unmask_rx_interrupts(cec);
> + s5p_cec_enable_rx(cec);
> + } else {
> + s5p_cec_mask_tx_interrupts(cec);
> + s5p_cec_mask_rx_interrupts(cec);
> + pm_runtime_disable(cec->dev);
> + }
> +
> + return 0;
> +}
> +
> +static int s5p_cec_log_addr(struct cec_adapter *adap, u8 addr)
> +{
> + struct s5p_cec_dev *cec = container_of(adap, struct s5p_cec_dev, adap);
> +
> + s5p_cec_set_addr(cec, addr);
> + return 0;
> +}
> +
> +static int s5p_cec_transmit(struct cec_adapter *adap, struct cec_msg *msg)
> +{
> + struct s5p_cec_dev *cec = container_of(adap, struct s5p_cec_dev, adap);
> +
> + s5p_cec_copy_packet(cec, msg->msg, msg->len);
> + return 0;
> +}
> +
> +static void s5p_cec_transmit_timed_out(struct cec_adapter *adap)
> +{
> +
> +}
> +
> +static irqreturn_t s5p_cec_irq_handler(int irq, void *priv)
> +{
> + struct s5p_cec_dev *cec = priv;
> + u32 status = 0;
> +
> + status = s5p_cec_get_status(cec);
> +
> + dev_dbg(cec->dev, "irq received\n");
> +
> + if (status & CEC_STATUS_TX_DONE) {
> + if (status & CEC_STATUS_TX_ERROR) {
> + dev_dbg(cec->dev, "CEC_STATUS_TX_ERROR set\n");
> + cec->tx = STATE_ERROR;
> + } else {
> + dev_dbg(cec->dev, "CEC_STATUS_TX_DONE\n");
> + cec->tx = STATE_DONE;
> + }
> + s5p_clr_pending_tx(cec);
> + }
> +
> + if (status & CEC_STATUS_RX_DONE) {
> + if (status & CEC_STATUS_RX_ERROR) {
> + dev_dbg(cec->dev, "CEC_STATUS_RX_ERROR set\n");
> + s5p_cec_rx_reset(cec);
> + s5p_cec_enable_rx(cec);
> + } else {
> + dev_dbg(cec->dev, "CEC_STATUS_RX_DONE set\n");
> + if (cec->rx != STATE_IDLE)
> + dev_dbg(cec->dev, "Buffer overrun (worker did
> not process previous message)\n");
> + cec->rx = STATE_BUSY;
> + cec->msg.len = status >> 24;
> + cec->msg.status = CEC_RX_STATUS_READY;
> + s5p_cec_get_rx_buf(cec, cec->msg.len,
> + cec->msg.msg);
> + cec->rx = STATE_DONE;
> + s5p_cec_enable_rx(cec);
> + }
> + /* Clear interrupt pending bit */
> + s5p_clr_pending_rx(cec);
> + }
> + return IRQ_WAKE_THREAD;
> +}
> +
> +static irqreturn_t s5p_cec_irq_handler_thread(int irq, void *priv)
> +{
> + struct s5p_cec_dev *cec = priv;
> +
> + dev_dbg(cec->dev, "irq pro
[PATCH] drm: sti: fix sub-components bind
Maxime, as STi DT maintainer, could you give us your point of view ? If needed I could split the patch in two: one for driver and one for DT. 2015-07-16 12:59 GMT+02:00 Thierry Reding : > On Wed, Jul 15, 2015 at 03:56:41PM +0200, Benjamin Gaignard wrote: >> It doesn't change any bindings fields, only remove one level of childs on DT. >> Old DTBs may not work but it will impact only very few peoples and no >> products so it isn't a problem. > > I know, that can be said of most platforms, but the decision was made to > consider DT a stable ABI, so you can't just go and break it. You'll have > to take this up with the ARM SoC maintainers. In the past they've been > known to request people to go through extra pain to avoid breaking DT > backwards-compatibility. > >> The patch fix driver and DT files so I don't think it could create issues. > > That doesn't count. Somebody could still be using an old DTB and not be > able (or unwilling) to reflash it. > > Irrespective, you're probably going to want to split up your patch into > driver and DTS changes. The DTS and binding changes will need to be > reviewed by the device tree maintainers, and I'd expect that the STi > maintainers will want to weigh in as well. > > Thierry > >> 2015-07-15 15:34 GMT+02:00 Thierry Reding : >> > On Wed, Jul 15, 2015 at 03:21:46PM +0200, Benjamin Gaignard wrote: >> >> Fix misunderstanding in how use component framework. >> >> drm_platform_init() is now call only when all the >> >> sub-components are register themselves instead of the >> >> previous two stages mechanism. >> >> >> >> Update devicetree and bindings documentation according >> >> to this new behavior. >> >> >> >> Signed-off-by: Benjamin Gaignard >> >> --- >> >> .../devicetree/bindings/gpu/st,stih4xx.txt | 7 +- >> >> arch/arm/boot/dts/stih407.dtsi | 82 >> >> +++--- >> >> arch/arm/boot/dts/stih410.dtsi | 82 >> >> +++--- >> >> drivers/gpu/drm/sti/sti_drm_drv.c | 45 ++-- >> >> drivers/gpu/drm/sti/sti_hdmi.c | 25 --- >> >> drivers/gpu/drm/sti/sti_tvout.c| 46 ++-- >> >> 6 files changed, 105 insertions(+), 182 deletions(-) >> > >> > Isn't this going to break DT ABI? How are you going to ensure backwards- >> > compatibility with old DTBs? >> > >> > Thierry >> >> >> >> -- >> Benjamin Gaignard >> >> Graphic Working Group >> >> Linaro.org â Open source software for ARM SoCs >> >> Follow Linaro: Facebook | Twitter | Blog -- Benjamin Gaignard Graphic Working Group Linaro.org â Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[Bug 91268] R6xx freezes with kernel 3.17 and up
https://bugs.freedesktop.org/show_bug.cgi?id=91268 --- Comment #16 from Alex Deucher --- (In reply to Kajzer from comment #15) > (In reply to Alex Deucher from comment #14) > > Do you see this bug if you don't enable dpm at all (which is the default)? > > Ah I get you now... I don't know, there's no point for me to even be on > Linux without dpm, but if you think that testing that would solve some > things then I guess I can try that. I'll let you know. Yes, please test. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/e6827358/attachment.html>
[Bug 91268] R6xx freezes with kernel 3.17 and up
https://bugs.freedesktop.org/show_bug.cgi?id=91268 --- Comment #15 from Kajzer --- (In reply to Alex Deucher from comment #14) > Do you see this bug if you don't enable dpm at all (which is the default)? Ah I get you now... I don't know, there's no point for me to even be on Linux without dpm, but if you think that testing that would solve some things then I guess I can try that. I'll let you know. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/0ea92985/attachment-0001.html>
[Bug 91268] R6xx freezes with kernel 3.17 and up
https://bugs.freedesktop.org/show_bug.cgi?id=91268 --- Comment #14 from Alex Deucher --- (In reply to Kajzer from comment #13) > If I don't set performance to high then it hangs all the time (not just in > gaming) and I can provoke it within minutes, regardless of kernel version. > This bug (CPU mappings) happens only while playing games and with kernels > above 3.16 > So, will this bug happen if I don't force performance to high ? > To be honest I don't know, been a while since I was on anything else other > than high, because for sure the other bug would happen, and they behave the > same when the hang happens. > So I guess it would hang if I don't force it. > Except maybe if there were some kind of mappings in the kernel before 3.17 > and that somehow both bugs are related. > That I don't know. Do you see this bug if you don't enable dpm at all (which is the default)? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/a33ad372/attachment.html>
[Bug 91268] R6xx freezes with kernel 3.17 and up
https://bugs.freedesktop.org/show_bug.cgi?id=91268 --- Comment #13 from Kajzer --- (In reply to Alex Deucher from comment #12) > Just to be clear, does this bug only happen when you force dpm on or all the > time? If I don't set performance to high then it hangs all the time (not just in gaming) and I can provoke it within minutes, regardless of kernel version. This bug (CPU mappings) happens only while playing games and with kernels above 3.16 So, will this bug happen if I don't force performance to high ? To be honest I don't know, been a while since I was on anything else other than high, because for sure the other bug would happen, and they behave the same when the hang happens. So I guess it would hang if I don't force it. Except maybe if there were some kind of mappings in the kernel before 3.17 and that somehow both bugs are related. That I don't know. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/0891a411/attachment.html>
[PATCH 01/13] drm/atomic: Only update crtc->x/y if it's part of the state.
On Thu, Jul 16, 2015 at 11:38:18AM +0200, Maarten Lankhorst wrote:
> Op 16-07-15 om 11:29 schreef Daniel Vetter:
> > On Thu, Jul 16, 2015 at 11:17:29AM +0200, Maarten Lankhorst wrote:
> >> Op 16-07-15 om 11:19 schreef Daniel Vetter:
> >>> On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst wrote:
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 0898afbc9e23..70e69904291d 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -667,8 +667,11 @@
> drm_atomic_helper_update_legacy_modeset_state(struct drm_device *dev,
> for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> crtc->mode = crtc->state->mode;
> crtc->enabled = crtc->state->enable;
> -crtc->x = crtc->primary->state->src_x >> 16;
> -crtc->y = crtc->primary->state->src_y >> 16;
> +
> +if (drm_atomic_get_existing_plane_state(old_state,
> crtc->primary)) {
> +crtc->x = crtc->primary->state->src_x >> 16;
> +crtc->y = crtc->primary->state->src_y >> 16;
> +}
> >>> What's the benefit here of only updating when something changed? The
> >>> atomic state should be the master source so copying a few too many times
> >>> shouldn't matter really.
> >> Because you might not be holding plane lock, so primary->state may be
> >> garbage.
> > Anyone who wants to touch primary plane must grab the crtc lock, so crtc
> > lock would give you an implicit read lock. At least that's been my
> > thinking, but it could be that the primary plane is used on some other
> > crtc, and then this is indeed garbage.
> This is only true if the plane is active. If there is none you can still
> update properties and
> swap the plane state without locking the crtc.
Ah right, so still possible to chase a being-freed primary->state pointer.
> > So maybe we need even more checks than what you propose:
> >
> > if (drm_atomic_get_existing_plane_state(old_state, crtc->primary) &&
> > crtc->primary->state->crtc == crtc) {
> > crtc->x = crtc->primary->state->src_x >> 16;
> > crtc->y = crtc->primary->state->src_y >> 16;
> > }
> >
> > I think a comment explaining this would help (or at least in the commit
> > message!).
> But the primary and cursor planes are not allowed to move between crtc's?
They are allowed to do that actually. crtc->primary and crtc->cursor is
only really a hint to implement backwards compatibility. If you have
generic plane hw with 2 crtc and planes can be freely assigned it would be
silly to artificially restrict the backwards compat planes to 1 crtc.
Otherwise we'd force 2 planes to be unusable when there's no external
screen plugged in, defeating a lot of the value of making planes freely
assignable.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Bug 91268] R6xx freezes with kernel 3.17 and up
https://bugs.freedesktop.org/show_bug.cgi?id=91268 --- Comment #12 from Alex Deucher --- Just to be clear, does this bug only happen when you force dpm on or all the time? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/adfea97b/attachment.html>
[Bug 91268] R6xx freezes with kernel 3.17 and up
https://bugs.freedesktop.org/show_bug.cgi?id=91268 Christian König changed: What|Removed |Added Attachment #117089|0 |1 is obsolete|| CC||deathsimple at vodafone.de --- Comment #11 from Christian König --- Created attachment 117172 --> https://bugs.freedesktop.org/attachment.cgi?id=117172&action=edit Disable uc/wc on anything older than R7xx Considering how old the hardware is I suggest that we just disable that feature for anything older than R7XX. A patch doing exactly this is attached. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/ba074959/attachment.html>
[PATCH 1/2] V4 regmap: Use reg_sequence for multi_reg_write / register_patch
On Tue, Jul 14, 2015 at 03:45:51PM +0100, Nariman Poushin wrote:
Please submit patches in the format covered in SubmittingPatches,
version information goes inside the [].
> Add support for writing sequences of registers / patches with specified
> delays (in microseconds). Logically separates the functionality using
> sequences of register writes from the functions that take register
> defaults, as adding a delay field on the reg_defaults can increase
> memory usage substantially.
This change doesn't do what the above changelog says. It introduces a
new struct reg_sequence and updates the multi write and patch APIs to
use that but it doesn't implement any delay functionality. Please
resend with a clearer changelog that describes why the struct is being
split out from the reg_defaults struct and makes it clear that this is
just a rename. It's probably best to also defer the addition of the
delay field until the second patch where this function is actually
implemented.
> +/**
> + * Register / Value pairs for sequences of writes, incorporating an optional
Register/value.
> + * delay in microseconds.
> + *
> + * @reg: Register address.
> + * @def: Register default value.
> + * @delay_us: Delay in microseconds
> + */
> +
> +struct reg_sequence {
No blank line between the kerneldoc and the struct (as is the style for
other kernel code).
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/6cdaab6b/attachment.sig>
[PATCH v9 1/4] drm/layerscape: Add Freescale DCU DRM driver
d LS1021A platforms?
> >
>
> Yes, Both VF610 and LS1021A use DCU as video IP module.
> And there are a bit of differences on each SoCs.
Yes, I understand. This should be covered by SoC-specific parameters
(via the of_device_id table) so that you can run the same kernel on both
VF610 and LS1021A SoCs.
As it is, if you build this on a configuration where both VF610 and
LS1021A are enabled you're going to pick up the values for VF610 and
cause LS1021A to not work.
> > > +void fsl_dcu_drm_plane_destroy(struct drm_plane *plane) {
> > > + fsl_dcu_drm_plane_disable(plane);
> >
> > Hmm? This function doesn't do anything, so why not just drop it?
> >
>
>
> I'll implement fsl_dcu_drm_plane_disable(plane)
>
>
>
> > > + drm_plane_cleanup(plane);
> > > +}
> >
> > Also this function and ->atomic_update() should be static. Perhaps make it
> > a habit of running your build tests with C=1 occasionally to get notified
> > of this kind of error.
> >
> > Thierry
>
>
>
> One question: How can I set C=1?
Just add it to the make command-line along with any other parameters,
like this for example:
$ make ARCH=arm CROSS_COMPILE=armv7l-unknown-linux-gnueabihf- \
O=build/vf610 C=1
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/4dadc8ad/attachment.sig>
[Bug 91268] R6xx freezes with kernel 3.17 and up
https://bugs.freedesktop.org/show_bug.cgi?id=91268 --- Comment #10 from Kajzer --- (In reply to Michel Dänzer from comment #9) > That's expected. Alex's patch isn't a fix but just to confirm the problem is > really directly related to write-combined CPU mappings. Yeah I know, that's what I really asked for, a way to disable that commit. I can confirm now that indeed there's some bug in that commit (with R6xx chips) I had no hangs with mappings disabled. I'm willing to test potential fixes. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/7fb72fe5/attachment-0001.html>
[PATCH] drm: sti: fix sub-components bind
On Wed, Jul 15, 2015 at 03:56:41PM +0200, Benjamin Gaignard wrote: > It doesn't change any bindings fields, only remove one level of childs on DT. > Old DTBs may not work but it will impact only very few peoples and no > products so it isn't a problem. I know, that can be said of most platforms, but the decision was made to consider DT a stable ABI, so you can't just go and break it. You'll have to take this up with the ARM SoC maintainers. In the past they've been known to request people to go through extra pain to avoid breaking DT backwards-compatibility. > The patch fix driver and DT files so I don't think it could create issues. That doesn't count. Somebody could still be using an old DTB and not be able (or unwilling) to reflash it. Irrespective, you're probably going to want to split up your patch into driver and DTS changes. The DTS and binding changes will need to be reviewed by the device tree maintainers, and I'd expect that the STi maintainers will want to weigh in as well. Thierry > 2015-07-15 15:34 GMT+02:00 Thierry Reding : > > On Wed, Jul 15, 2015 at 03:21:46PM +0200, Benjamin Gaignard wrote: > >> Fix misunderstanding in how use component framework. > >> drm_platform_init() is now call only when all the > >> sub-components are register themselves instead of the > >> previous two stages mechanism. > >> > >> Update devicetree and bindings documentation according > >> to this new behavior. > >> > >> Signed-off-by: Benjamin Gaignard > >> --- > >> .../devicetree/bindings/gpu/st,stih4xx.txt | 7 +- > >> arch/arm/boot/dts/stih407.dtsi | 82 > >> +++--- > >> arch/arm/boot/dts/stih410.dtsi | 82 > >> +++--- > >> drivers/gpu/drm/sti/sti_drm_drv.c | 45 ++-- > >> drivers/gpu/drm/sti/sti_hdmi.c | 25 --- > >> drivers/gpu/drm/sti/sti_tvout.c| 46 ++-- > >> 6 files changed, 105 insertions(+), 182 deletions(-) > > > > Isn't this going to break DT ABI? How are you going to ensure backwards- > > compatibility with old DTBs? > > > > Thierry > > > > -- > Benjamin Gaignard > > Graphic Working Group > > Linaro.org â Open source software for ARM SoCs > > Follow Linaro: Facebook | Twitter | Blog -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/621fcbba/attachment.sig>
[PATCH] drm: rcar-du: Add dependency to OF
Hi Geert, On Thursday 16 July 2015 11:08:58 Geert Uytterhoeven wrote: > On Thu, Jul 16, 2015 at 10:44 AM, Laurent Pinchart wrote: > > The driver requires OF support, add a dependency in Kconfig and remove > > the platform_device_id table that isn't used anymore. > > > > Signed-off-by: Laurent Pinchart > > > > Once Simon has queued up the removal of board-marzen.c: > > Acked-by: Geert Uytterhoeven Thank you. Note that support for platform data in the rcar-du driver has been dropped in v3.19, so I don't think we need to wait until Simon queues up the removal of board-marzen.c. -- Regards, Laurent Pinchart
[PATCH v2 00/23] drm/exynos: atomic improvements + exynos_encoder removal
2015-07-14 Joonyoung Shim : > On 07/06/2015 11:20 PM, Gustavo Padovan wrote: > > From: Gustavo Padovan > > > > Hi, > > > > This set improves exynos in a number of ways. The first five patches are > > general clean up/fixes. > > > > Patches 06 to 12 are improvements on top of the newly added atomic > > modesetting > > support. > > > > Patches 13-23 are a big journey to completely remove the internal > > exynos_drm_encoder struct. Now exynos encoders register themselves directly > > with the drm core. > > I got compile error with 13-23 patches. > > drivers/gpu/drm/exynos/exynos_drm_dsi.c: In function âexynos_dsi_bindâ: > drivers/gpu/drm/exynos/exynos_drm_dsi.c:1839:3: error: âdisplayâ > undeclared (first use in this function) >display->encoder->bridge = bridge; >^ > drivers/gpu/drm/exynos/exynos_drm_dsi.c:1839:3: note: each undeclared > identifier is reported only once for each function it appears in > make[4]: *** [drivers/gpu/drm/exynos/exynos_drm_dsi.o] Error 1 > > > If you post the stuff that only be related, it will be reviewed and > merged easier. > > 01-04 and 06-11 patches look good to me, about them, > Reviewed-by: Joonyoung Shim Sure, I've resent only the patch with your Reviewed-by in a separate patchset. The others will come in another patcheset. Gustavo
[PATCH v3 9/9] drm/exynos: return return value of exynos_crtc->enable_vblank
From: Gustavo Padovan Instead of blindly ignore the return value of enable_vblank return it to the upper DRM layer for error handling. Suggested-by: Joonyoung Shim Signed-off-by: Gustavo Padovan Reviewed-by: Joonyoung Shim --- drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c b/drivers/gpu/drm/exynos/exynos_drm_crtc.c index e9c291f..9bc2353 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c @@ -175,7 +175,7 @@ int exynos_drm_crtc_enable_vblank(struct drm_device *dev, int pipe) return -EPERM; if (exynos_crtc->ops->enable_vblank) - exynos_crtc->ops->enable_vblank(exynos_crtc); + return exynos_crtc->ops->enable_vblank(exynos_crtc); return 0; } -- 2.1.0
[PATCH v3 8/9] drm/exynos: unify exynos_drm_plane names with drm core
From: Gustavo Padovan
Rename crtc_{widht,height} to crtc_{w,h} and src_{width,height} to
src_{w,h} to make it similar to the atomic state names.
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 10 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 14 +++---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 16
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 14 +++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 11 ++-
drivers/gpu/drm/exynos/exynos_mixer.c | 22 +++---
6 files changed, 44 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index dd41390..e50e6bb 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -237,8 +237,8 @@ static void decon_update_plane(struct exynos_drm_crtc *crtc,
val = COORDINATE_X(plane->crtc_x) | COORDINATE_Y(plane->crtc_y);
writel(val, ctx->addr + DECON_VIDOSDxA(win));
- val = COORDINATE_X(plane->crtc_x + plane->crtc_width - 1) |
- COORDINATE_Y(plane->crtc_y + plane->crtc_height - 1);
+ val = COORDINATE_X(plane->crtc_x + plane->crtc_w - 1) |
+ COORDINATE_Y(plane->crtc_y + plane->crtc_h - 1);
writel(val, ctx->addr + DECON_VIDOSDxB(win));
val = VIDOSD_Wx_ALPHA_R_F(0x0) | VIDOSD_Wx_ALPHA_G_F(0x0) |
@@ -251,11 +251,11 @@ static void decon_update_plane(struct exynos_drm_crtc
*crtc,
writel(plane->dma_addr[0], ctx->addr + DECON_VIDW0xADD0B0(win));
- val = plane->dma_addr[0] + pitch * plane->crtc_height;
+ val = plane->dma_addr[0] + pitch * plane->crtc_h;
writel(val, ctx->addr + DECON_VIDW0xADD1B0(win));
- val = OFFSIZE(pitch - plane->crtc_width * bpp)
- | PAGEWIDTH(plane->crtc_width * bpp);
+ val = OFFSIZE(pitch - plane->crtc_w * bpp)
+ | PAGEWIDTH(plane->crtc_w * bpp);
writel(val, ctx->addr + DECON_VIDW0xADD2(win));
decon_win_set_pixfmt(ctx, win, state->fb);
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 7f00a20..85657cf 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -429,25 +429,25 @@ static void decon_update_plane(struct exynos_drm_crtc
*crtc,
DRM_DEBUG_KMS("start addr = 0x%lx\n",
(unsigned long)val);
DRM_DEBUG_KMS("ovl_width = %d, ovl_height = %d\n",
- plane->crtc_width, plane->crtc_height);
+ plane->crtc_w, plane->crtc_h);
/*
* OSD position.
* In case the window layout goes of LCD layout, DECON fails.
*/
- if ((plane->crtc_x + plane->crtc_width) > mode->hdisplay)
- plane->crtc_x = mode->hdisplay - plane->crtc_width;
- if ((plane->crtc_y + plane->crtc_height) > mode->vdisplay)
- plane->crtc_y = mode->vdisplay - plane->crtc_height;
+ if ((plane->crtc_x + plane->crtc_w) > mode->hdisplay)
+ plane->crtc_x = mode->hdisplay - plane->crtc_w;
+ if ((plane->crtc_y + plane->crtc_h) > mode->vdisplay)
+ plane->crtc_y = mode->vdisplay - plane->crtc_h;
val = VIDOSDxA_TOPLEFT_X(plane->crtc_x) |
VIDOSDxA_TOPLEFT_Y(plane->crtc_y);
writel(val, ctx->regs + VIDOSD_A(win));
- last_x = plane->crtc_x + plane->crtc_width;
+ last_x = plane->crtc_x + plane->crtc_w;
if (last_x)
last_x--;
- last_y = plane->crtc_y + plane->crtc_height;
+ last_y = plane->crtc_y + plane->crtc_h;
if (last_y)
last_y--;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 00e4145..5d7ae07 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -44,12 +44,12 @@ enum exynos_drm_output_type {
* - the unit is screen coordinates.
* @src_y: offset y on a framebuffer to be displayed.
* - the unit is screen coordinates.
- * @src_width: width of a partial image to be displayed from framebuffer.
- * @src_height: height of a partial image to be displayed from framebuffer.
+ * @src_w: width of a partial image to be displayed from framebuffer.
+ * @src_h: height of a partial image to be displayed from framebuffer.
* @crtc_x: offset x on hardware screen.
* @crtc_y: offset y on hardware screen.
- * @crtc_width: window width to be displayed (hardware screen).
- * @crtc_height: window height to be displayed (hardware screen).
+ * @crtc_w: window width to be displayed (hardware screen).
+ * @crtc_h: window height to be displayed (hardware screen).
* @h_ratio: horizontal scaling ratio, 16.16 fixed point
* @v_ratio: vertical scaling ratio, 16.16 fixed point
* @d
[PATCH v3 7/9] drm/exynos: remove unused fields from struct exynos_drm_plane
From: Gustavo Padovan
Now after the move to use drm_plane_state directly struct drm_plane_state
has many unused fields, along with others that weren't used before the
plane state change. Thus remove them all.
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 18 --
1 file changed, 18 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index cec46b6..00e4145 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -46,21 +46,12 @@ enum exynos_drm_output_type {
* - the unit is screen coordinates.
* @src_width: width of a partial image to be displayed from framebuffer.
* @src_height: height of a partial image to be displayed from framebuffer.
- * @fb_width: width of a framebuffer.
- * @fb_height: height of a framebuffer.
* @crtc_x: offset x on hardware screen.
* @crtc_y: offset y on hardware screen.
* @crtc_width: window width to be displayed (hardware screen).
* @crtc_height: window height to be displayed (hardware screen).
- * @mode_width: width of screen mode.
- * @mode_height: height of screen mode.
* @h_ratio: horizontal scaling ratio, 16.16 fixed point
* @v_ratio: vertical scaling ratio, 16.16 fixed point
- * @refresh: refresh rate.
- * @scan_flag: interlace or progressive way.
- * (it could be DRM_MODE_FLAG_*)
- * @bpp: pixel size.(in bit)
- * @pixel_format: fourcc pixel format of this overlay
* @dma_addr: array of bus(accessed by dma) address to the memory region
* allocated for a overlay.
* @zpos: order of overlay layer(z position).
@@ -75,21 +66,12 @@ struct exynos_drm_plane {
unsigned int src_y;
unsigned int src_width;
unsigned int src_height;
- unsigned int fb_width;
- unsigned int fb_height;
unsigned int crtc_x;
unsigned int crtc_y;
unsigned int crtc_width;
unsigned int crtc_height;
- unsigned int mode_width;
- unsigned int mode_height;
unsigned int h_ratio;
unsigned int v_ratio;
- unsigned int refresh;
- unsigned int scan_flag;
- unsigned int bpp;
- unsigned int pitch;
- uint32_t pixel_format;
dma_addr_t dma_addr[MAX_FB_BUFFER];
unsigned int zpos;
};
--
2.1.0
[PATCH v3 6/9] drm/exynos: use drm atomic state directly
From: Gustavo Padovan
For some fields the use of struct exynos_drm_plane filled with data from
the plane state just creates a source of duplicated information and
overhead. Here we change the crtc drivers to access the plane state
directly simplifying the code by not relying on a exynos internal struct.
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 21 +
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 23 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 29 ++--
drivers/gpu/drm/exynos/exynos_drm_plane.c | 12 -
drivers/gpu/drm/exynos/exynos_mixer.c | 65 ++-
5 files changed, 75 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 6dc2be2..dd41390 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -152,15 +152,15 @@ static void decon_commit(struct exynos_drm_crtc *crtc)
#define OFFSIZE(x) (((x) & 0x3fff) << 14)
#define PAGEWIDTH(x) ((x) & 0x3fff)
-static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win)
+static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
+struct drm_framebuffer *fb)
{
- struct exynos_drm_plane *plane = &ctx->planes[win];
unsigned long val;
val = readl(ctx->addr + DECON_WINCONx(win));
val &= ~WINCONx_BPPMODE_MASK;
- switch (plane->pixel_format) {
+ switch (fb->pixel_format) {
case DRM_FORMAT_XRGB1555:
val |= WINCONx_BPPMODE_16BPP_I1555;
val |= WINCONx_HAWSWP_F;
@@ -186,7 +186,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx,
unsigned int win)
return;
}
- DRM_DEBUG_KMS("bpp = %u\n", plane->bpp);
+ DRM_DEBUG_KMS("bpp = %u\n", fb->bits_per_pixel);
/*
* In case of exynos, setting dma-burst to 16Word causes permanent
@@ -196,7 +196,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx,
unsigned int win)
* movement causes unstable DMA which results into iommu crash/tear.
*/
- if (plane->fb_width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
+ if (fb->width < MIN_FB_WIDTH_FOR_16WORD_BURST) {
val &= ~WINCONx_BURSTLEN_MASK;
val |= WINCONx_BURSTLEN_8WORD;
}
@@ -223,7 +223,10 @@ static void decon_update_plane(struct exynos_drm_crtc
*crtc,
struct exynos_drm_plane *plane)
{
struct decon_context *ctx = crtc->ctx;
+ struct drm_plane_state *state = plane->base.state;
unsigned int win = plane->zpos;
+ unsigned int bpp = state->fb->bits_per_pixel >> 3;
+ unsigned int pitch = state->fb->pitches[0];
u32 val;
if (ctx->suspended)
@@ -248,14 +251,14 @@ static void decon_update_plane(struct exynos_drm_crtc
*crtc,
writel(plane->dma_addr[0], ctx->addr + DECON_VIDW0xADD0B0(win));
- val = plane->dma_addr[0] + plane->pitch * plane->crtc_height;
+ val = plane->dma_addr[0] + pitch * plane->crtc_height;
writel(val, ctx->addr + DECON_VIDW0xADD1B0(win));
- val = OFFSIZE(plane->pitch - plane->crtc_width * (plane->bpp >> 3))
- | PAGEWIDTH(plane->crtc_width * (plane->bpp >> 3));
+ val = OFFSIZE(pitch - plane->crtc_width * bpp)
+ | PAGEWIDTH(plane->crtc_width * bpp);
writel(val, ctx->addr + DECON_VIDW0xADD2(win));
- decon_win_set_pixfmt(ctx, win);
+ decon_win_set_pixfmt(ctx, win, state->fb);
/* window enable */
val = readl(ctx->addr + DECON_WINCONx(win));
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 79b74d2..7f00a20 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -271,16 +271,16 @@ static void decon_disable_vblank(struct exynos_drm_crtc
*crtc)
}
}
-static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win)
+static void decon_win_set_pixfmt(struct decon_context *ctx, unsigned int win,
+struct drm_framebuffer *fb)
{
- struct exynos_drm_plane *plane = &ctx->planes[win];
unsigned long val;
int padding;
val = readl(ctx->regs + WINCON(win));
val &= ~WINCONx_BPPMODE_MASK;
- switch (plane->pixel_format) {
+ switch (fb->pixel_format) {
case DRM_FORMAT_RGB565:
val |= WINCONx_BPPMODE_16BPP_565;
val |= WINCONx_BURSTLEN_16WORD;
@@ -329,7 +329,7 @@ static void decon_win_set_pixfmt(struct decon_context *ctx,
unsigned int win)
break;
}
- DRM_DEBUG_KMS("bpp = %d\n", plane->bpp);
+ DRM_DEBUG_KMS("bpp = %d\n", fb->bits_per_pixel);
[PATCH v3 5/9] drm/exynos: pass struct exynos_drm_plane in update/enable
From: Gustavo Padovan
We already have the plane pointer in before calling .update_plane() or
disable_plane() so pass it directly to those calls avoiding a new
conversion from zpos to struct exynos_drm_plane.
v2: don't remove check for suspended in FIMD (comment by Joonyoung)
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 22 +++---
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 22 +++---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 6 --
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 22 +++---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 4 ++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 9 ++---
drivers/gpu/drm/exynos/exynos_mixer.c | 20 +++-
7 files changed, 40 insertions(+), 65 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index c7f3680..6dc2be2 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -219,17 +219,13 @@ static void decon_shadow_protect_win(struct decon_context
*ctx, int win,
writel(val, ctx->addr + DECON_SHADOWCON);
}
-static void decon_update_plane(struct exynos_drm_crtc *crtc, unsigned int win)
+static void decon_update_plane(struct exynos_drm_crtc *crtc,
+ struct exynos_drm_plane *plane)
{
struct decon_context *ctx = crtc->ctx;
- struct exynos_drm_plane *plane;
+ unsigned int win = plane->zpos;
u32 val;
- if (win < 0 || win >= WINDOWS_NR)
- return;
-
- plane = &ctx->planes[win];
-
if (ctx->suspended)
return;
@@ -277,17 +273,13 @@ static void decon_update_plane(struct exynos_drm_crtc
*crtc, unsigned int win)
atomic_set(&ctx->win_updated, 1);
}
-static void decon_disable_plane(struct exynos_drm_crtc *crtc, unsigned int win)
+static void decon_disable_plane(struct exynos_drm_crtc *crtc,
+ struct exynos_drm_plane *plane)
{
struct decon_context *ctx = crtc->ctx;
- struct exynos_drm_plane *plane;
+ unsigned int win = plane->zpos;
u32 val;
- if (win < 0 || win >= WINDOWS_NR)
- return;
-
- plane = &ctx->planes[win];
-
if (ctx->suspended)
return;
@@ -378,7 +370,7 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
* a destroyed buffer later.
*/
for (i = 0; i < WINDOWS_NR; i++)
- decon_disable_plane(crtc, i);
+ decon_disable_plane(crtc, &ctx->planes[i]);
decon_swreset(ctx);
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 34da2a4..79b74d2 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -382,24 +382,20 @@ static void decon_shadow_protect_win(struct decon_context
*ctx,
writel(val, ctx->regs + SHADOWCON);
}
-static void decon_update_plane(struct exynos_drm_crtc *crtc, unsigned int win)
+static void decon_update_plane(struct exynos_drm_crtc *crtc,
+ struct exynos_drm_plane *plane)
{
struct decon_context *ctx = crtc->ctx;
struct drm_display_mode *mode = &crtc->base.state->adjusted_mode;
- struct exynos_drm_plane *plane;
int padding;
unsigned long val, alpha;
unsigned int last_x;
unsigned int last_y;
+ unsigned int win = plane->zpos;
if (ctx->suspended)
return;
- if (win < 0 || win >= WINDOWS_NR)
- return;
-
- plane = &ctx->planes[win];
-
/*
* SHADOWCON/PRTCON register is used for enabling timing.
*
@@ -492,17 +488,13 @@ static void decon_update_plane(struct exynos_drm_crtc
*crtc, unsigned int win)
writel(val, ctx->regs + DECON_UPDATE);
}
-static void decon_disable_plane(struct exynos_drm_crtc *crtc, unsigned int win)
+static void decon_disable_plane(struct exynos_drm_crtc *crtc,
+ struct exynos_drm_plane *plane)
{
struct decon_context *ctx = crtc->ctx;
- struct exynos_drm_plane *plane;
+ unsigned int win = plane->zpos;
u32 val;
- if (win < 0 || win >= WINDOWS_NR)
- return;
-
- plane = &ctx->planes[win];
-
if (ctx->suspended)
return;
@@ -598,7 +590,7 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
* a destroyed buffer later.
*/
for (i = 0; i < WINDOWS_NR; i++)
- decon_disable_plane(crtc, i);
+ decon_disable_plane(crtc, &ctx->planes[i]);
clk_disable_unprepare(ctx->vclk);
clk_disable_unprepare(ctx->eclk);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_dr
[PATCH v3 4/9] drm/exynos: rename win_commit/disable to atomic-like names
From: Gustavo Padovan
Rename win_commit() helper to update_plane() and win_disable() to
disable_plane().
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 10 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 10 +-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 8
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 10 +-
drivers/gpu/drm/exynos/exynos_drm_plane.c | 10 +-
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 6 +++---
drivers/gpu/drm/exynos/exynos_mixer.c | 10 +-
7 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 61e6e4a..c7f3680 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -219,7 +219,7 @@ static void decon_shadow_protect_win(struct decon_context
*ctx, int win,
writel(val, ctx->addr + DECON_SHADOWCON);
}
-static void decon_win_commit(struct exynos_drm_crtc *crtc, unsigned int win)
+static void decon_update_plane(struct exynos_drm_crtc *crtc, unsigned int win)
{
struct decon_context *ctx = crtc->ctx;
struct exynos_drm_plane *plane;
@@ -277,7 +277,7 @@ static void decon_win_commit(struct exynos_drm_crtc *crtc,
unsigned int win)
atomic_set(&ctx->win_updated, 1);
}
-static void decon_win_disable(struct exynos_drm_crtc *crtc, unsigned int win)
+static void decon_disable_plane(struct exynos_drm_crtc *crtc, unsigned int win)
{
struct decon_context *ctx = crtc->ctx;
struct exynos_drm_plane *plane;
@@ -378,7 +378,7 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
* a destroyed buffer later.
*/
for (i = 0; i < WINDOWS_NR; i++)
- decon_win_disable(crtc, i);
+ decon_disable_plane(crtc, i);
decon_swreset(ctx);
@@ -460,8 +460,8 @@ static struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable_vblank = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
.commit = decon_commit,
- .win_commit = decon_win_commit,
- .win_disable= decon_win_disable,
+ .update_plane = decon_update_plane,
+ .disable_plane = decon_disable_plane,
.te_handler = decon_te_irq_handler,
.clear_channels = decon_clear_channels,
};
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index f720f2a..34da2a4 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -382,7 +382,7 @@ static void decon_shadow_protect_win(struct decon_context
*ctx,
writel(val, ctx->regs + SHADOWCON);
}
-static void decon_win_commit(struct exynos_drm_crtc *crtc, unsigned int win)
+static void decon_update_plane(struct exynos_drm_crtc *crtc, unsigned int win)
{
struct decon_context *ctx = crtc->ctx;
struct drm_display_mode *mode = &crtc->base.state->adjusted_mode;
@@ -492,7 +492,7 @@ static void decon_win_commit(struct exynos_drm_crtc *crtc,
unsigned int win)
writel(val, ctx->regs + DECON_UPDATE);
}
-static void decon_win_disable(struct exynos_drm_crtc *crtc, unsigned int win)
+static void decon_disable_plane(struct exynos_drm_crtc *crtc, unsigned int win)
{
struct decon_context *ctx = crtc->ctx;
struct exynos_drm_plane *plane;
@@ -598,7 +598,7 @@ static void decon_disable(struct exynos_drm_crtc *crtc)
* a destroyed buffer later.
*/
for (i = 0; i < WINDOWS_NR; i++)
- decon_win_disable(crtc, i);
+ decon_disable_plane(crtc, i);
clk_disable_unprepare(ctx->vclk);
clk_disable_unprepare(ctx->eclk);
@@ -618,8 +618,8 @@ static const struct exynos_drm_crtc_ops decon_crtc_ops = {
.enable_vblank = decon_enable_vblank,
.disable_vblank = decon_disable_vblank,
.wait_for_vblank = decon_wait_for_vblank,
- .win_commit = decon_win_commit,
- .win_disable = decon_win_disable,
+ .update_plane = decon_update_plane,
+ .disable_plane = decon_disable_plane,
.clear_channels = decon_clear_channels,
};
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index dd00f16..77da485 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -153,8 +153,8 @@ struct exynos_drm_display {
* @disable_vblank: specific driver callback for disabling vblank interrupt.
* @wait_for_vblank: wait for vblank interrupt to make sure that
* hardware overlay is updated.
- * @win_commit: apply hardware specific overlay data to registers.
- * @win_disable: disable hardware specific overlay.
+ * @update_plane: apply hardware specific overla
[PATCH v3 3/9] drm/exynos: remove duplicated check for suspend
From: Gustavo Padovan The same check is placed twice in fimd/decon_update_plane(), remove one of them. Signed-off-by: Gustavo Padovan Reviewed-by: Joonyoung Shim --- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 3 --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 3 --- 2 files changed, 6 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c b/drivers/gpu/drm/exynos/exynos7_drm_decon.c index 5a1174a..f720f2a 100644 --- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c +++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c @@ -400,9 +400,6 @@ static void decon_win_commit(struct exynos_drm_crtc *crtc, unsigned int win) plane = &ctx->planes[win]; - if (ctx->suspended) - return; - /* * SHADOWCON/PRTCON register is used for enabling timing. * diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c b/drivers/gpu/drm/exynos/exynos_drm_fimd.c index 9eb9e33..0875f111 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimd.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimd.c @@ -630,9 +630,6 @@ static void fimd_win_commit(struct exynos_drm_crtc *crtc, unsigned int win) plane = &ctx->planes[win]; - if (ctx->suspended) - return; - /* * SHADOWCON/PRTCON register is used for enabling timing. * -- 2.1.0
[PATCH v3 2/9] drm/exynos: use KMS version of DRM vblanks functions
From: Gustavo Padovan
Get rid of legacy DRM vblank function that are less clear to use.
The new ones basically requires only the crtc as parameters.
It also clean ups exynos_drm_crtc_finish_pageflip() parameters as a
consequence.
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 6 +++---
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 4 ++--
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 14 ++
drivers/gpu/drm/exynos/exynos_drm_crtc.h | 2 +-
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 8
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 4 ++--
drivers/gpu/drm/exynos/exynos_mixer.c | 4 ++--
7 files changed, 20 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
index 8b1225f..61e6e4a 100644
--- a/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos5433_drm_decon.c
@@ -407,7 +407,7 @@ void decon_te_irq_handler(struct exynos_drm_crtc *crtc)
writel(val, ctx->addr + DECON_TRIGCON);
}
- drm_handle_vblank(ctx->drm_dev, ctx->pipe);
+ drm_crtc_handle_vblank(&ctx->crtc->base);
}
static void decon_clear_channels(struct exynos_drm_crtc *crtc)
@@ -533,7 +533,7 @@ static irqreturn_t decon_vsync_irq_handler(int irq, void
*dev_id)
val = readl(ctx->addr + DECON_VIDINTCON1);
if (val & VIDINTCON1_INTFRMPEND) {
- drm_handle_vblank(ctx->drm_dev, ctx->pipe);
+ drm_crtc_handle_vblank(&ctx->crtc->base);
/* clear */
writel(VIDINTCON1_INTFRMPEND, ctx->addr + DECON_VIDINTCON1);
@@ -553,7 +553,7 @@ static irqreturn_t decon_lcd_sys_irq_handler(int irq, void
*dev_id)
val = readl(ctx->addr + DECON_VIDINTCON1);
if (val & VIDINTCON1_INTFRMDONEPEND) {
- exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
+ exynos_drm_crtc_finish_pageflip(ctx->crtc);
/* clear */
writel(VIDINTCON1_INTFRMDONEPEND,
diff --git a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
index 362532a..5a1174a 100644
--- a/drivers/gpu/drm/exynos/exynos7_drm_decon.c
+++ b/drivers/gpu/drm/exynos/exynos7_drm_decon.c
@@ -643,8 +643,8 @@ static irqreturn_t decon_irq_handler(int irq, void *dev_id)
goto out;
if (!ctx->i80_if) {
- drm_handle_vblank(ctx->drm_dev, ctx->pipe);
- exynos_drm_crtc_finish_pageflip(ctx->drm_dev, ctx->pipe);
+ drm_crtc_handle_vblank(&ctx->crtc->base);
+ exynos_drm_crtc_finish_pageflip(ctx->crtc);
/* set wait vsync event to zero and wake up queue. */
if (atomic_read(&ctx->wait_vsync_event)) {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 22b9ca0..e9c291f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -193,24 +193,22 @@ void exynos_drm_crtc_disable_vblank(struct drm_device
*dev, int pipe)
exynos_crtc->ops->disable_vblank(exynos_crtc);
}
-void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe)
+void exynos_drm_crtc_finish_pageflip(struct exynos_drm_crtc *exynos_crtc)
{
- struct exynos_drm_private *dev_priv = dev->dev_private;
- struct drm_crtc *drm_crtc = dev_priv->crtc[pipe];
- struct exynos_drm_crtc *exynos_crtc = to_exynos_crtc(drm_crtc);
+ struct drm_crtc *crtc = &exynos_crtc->base;
unsigned long flags;
- spin_lock_irqsave(&dev->event_lock, flags);
+ spin_lock_irqsave(&crtc->dev->event_lock, flags);
if (exynos_crtc->event) {
- drm_send_vblank_event(dev, pipe, exynos_crtc->event);
- drm_vblank_put(dev, pipe);
+ drm_crtc_send_vblank_event(crtc, exynos_crtc->event);
+ drm_crtc_vblank_put(crtc);
wake_up(&exynos_crtc->pending_flip_queue);
}
exynos_crtc->event = NULL;
- spin_unlock_irqrestore(&dev->event_lock, flags);
+ spin_unlock_irqrestore(&crtc->dev->event_lock, flags);
}
void exynos_drm_crtc_complete_scanout(struct drm_framebuffer *fb)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
index 0f3aa70..d01d49a 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.h
@@ -25,7 +25,7 @@ struct exynos_drm_crtc *exynos_drm_crtc_create(struct
drm_device *drm_dev,
void *context);
int exynos_drm_crtc_enable_vblank(struct drm_device *dev, int pipe);
void exynos_drm_crtc_disable_vblank(struct drm_device *dev, int pipe);
-void exynos_drm_crtc_finish_pageflip(struct drm_device *dev, int pipe);
+void exynos_drm_crtc_finish_pageflip(struct exynos_drm_crtc *
[PATCH v3 1/9] drm/exynos: pass the correct pipe number
From: Gustavo Padovan
Instead of giving -1 to as arg to drm_send_vblank_event() pass the
correct pipe number to it.
Signed-off-by: Gustavo Padovan
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index 644b4b7..22b9ca0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -203,7 +203,7 @@ void exynos_drm_crtc_finish_pageflip(struct drm_device
*dev, int pipe)
spin_lock_irqsave(&dev->event_lock, flags);
if (exynos_crtc->event) {
- drm_send_vblank_event(dev, -1, exynos_crtc->event);
+ drm_send_vblank_event(dev, pipe, exynos_crtc->event);
drm_vblank_put(dev, pipe);
wake_up(&exynos_crtc->pending_flip_queue);
--
2.1.0
[PATCH] drm: rcar-du: Add dependency to OF
The driver requires OF support, add a dependency in Kconfig and remove
the platform_device_id table that isn't used anymore.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Kconfig | 2 +-
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +--
2 files changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 11485a4a16ae..d4e0a39568f6 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -1,6 +1,6 @@
config DRM_RCAR_DU
tristate "DRM Support for R-Car Display Unit"
- depends on DRM && ARM && HAVE_DMA_ATTRS
+ depends on DRM && ARM && HAVE_DMA_ATTRS && OF
depends on ARCH_SHMOBILE || COMPILE_TEST
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index fb6709160a59..a9c445f1ebff 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -106,13 +106,6 @@ static const struct rcar_du_device_info
rcar_du_r8a7791_info = {
.num_lvds = 1,
};
-static const struct platform_device_id rcar_du_id_table[] = {
- { "rcar-du-r8a7779", (kernel_ulong_t)&rcar_du_r8a7779_info },
- { }
-};
-
-MODULE_DEVICE_TABLE(platform, rcar_du_id_table);
-
static const struct of_device_id rcar_du_of_table[] = {
{ .compatible = "renesas,du-r8a7779", .data = &rcar_du_r8a7779_info },
{ .compatible = "renesas,du-r8a7790", .data = &rcar_du_r8a7790_info },
@@ -165,8 +158,7 @@ static int rcar_du_load(struct drm_device *dev, unsigned
long flags)
init_waitqueue_head(&rcdu->commit.wait);
rcdu->dev = &pdev->dev;
- rcdu->info = np ? of_match_device(rcar_du_of_table, rcdu->dev)->data
- : (void *)platform_get_device_id(pdev)->driver_data;
+ rcdu->info = of_match_device(rcar_du_of_table, rcdu->dev)->data;
rcdu->ddev = dev;
dev->dev_private = rcdu;
@@ -338,7 +330,6 @@ static struct platform_driver rcar_du_platform_driver = {
.pm = &rcar_du_pm_ops,
.of_match_table = rcar_du_of_table,
},
- .id_table = rcar_du_id_table,
};
module_platform_driver(rcar_du_platform_driver);
--
Regards,
Laurent Pinchart
[PATCH 01/13] drm/atomic: Only update crtc->x/y if it's part of the state.
Op 16-07-15 om 11:29 schreef Daniel Vetter:
> On Thu, Jul 16, 2015 at 11:17:29AM +0200, Maarten Lankhorst wrote:
>> Op 16-07-15 om 11:19 schreef Daniel Vetter:
>>> On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst wrote:
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 0898afbc9e23..70e69904291d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -667,8 +667,11 @@ drm_atomic_helper_update_legacy_modeset_state(struct
drm_device *dev,
for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
crtc->mode = crtc->state->mode;
crtc->enabled = crtc->state->enable;
- crtc->x = crtc->primary->state->src_x >> 16;
- crtc->y = crtc->primary->state->src_y >> 16;
+
+ if (drm_atomic_get_existing_plane_state(old_state,
crtc->primary)) {
+ crtc->x = crtc->primary->state->src_x >> 16;
+ crtc->y = crtc->primary->state->src_y >> 16;
+ }
>>> What's the benefit here of only updating when something changed? The
>>> atomic state should be the master source so copying a few too many times
>>> shouldn't matter really.
>> Because you might not be holding plane lock, so primary->state may be
>> garbage.
> Anyone who wants to touch primary plane must grab the crtc lock, so crtc
> lock would give you an implicit read lock. At least that's been my
> thinking, but it could be that the primary plane is used on some other
> crtc, and then this is indeed garbage.
This is only true if the plane is active. If there is none you can still update
properties and
swap the plane state without locking the crtc.
> So maybe we need even more checks than what you propose:
>
> if (drm_atomic_get_existing_plane_state(old_state, crtc->primary) &&
> crtc->primary->state->crtc == crtc) {
> crtc->x = crtc->primary->state->src_x >> 16;
> crtc->y = crtc->primary->state->src_y >> 16;
> }
>
> I think a comment explaining this would help (or at least in the commit
> message!).
But the primary and cursor planes are not allowed to move between crtc's?
~Maarten
[PATCH 02/13] drm/atomic: Update legacy DPMS state during modesets.
On Thu, Jul 16, 2015 at 11:24:02AM +0200, Maarten Lankhorst wrote:
> Op 16-07-15 om 11:19 schreef Daniel Vetter:
> > On Thu, Jul 16, 2015 at 10:59:15AM +0200, Maarten Lankhorst wrote:
> >> This is required for DPMS to work correctly, during a modeset
> >> the DPMS property should be turned off, unless the crtc
> >> is made active in which case it should be set to DPMS on.
> >>
> >> Cc: dri-devel at lists.freedesktop.org
> >> Signed-off-by: Maarten Lankhorst
> >> ---
> >> drivers/gpu/drm/drm_atomic_helper.c | 16 ++--
> >> 1 file changed, 14 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index 70e69904291d..cdec643971a2 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -642,6 +642,12 @@ drm_atomic_helper_update_legacy_modeset_state(struct
> >> drm_device *dev,
> >>
> >>/* clear out existing links */
> >>for_each_connector_in_state(old_state, connector, old_conn_state, i) {
> >> + struct drm_crtc *crtc = connector->state->crtc;
> >> +
> >> + if (crtc &&
> >> + drm_atomic_crtc_needs_modeset(crtc->state))
> >> + connector->dpms = DRM_MODE_DPMS_OFF;
> > Same here, why only update when something changed? I already applied my
> > patch from yesterday which updates this always (with Daniel Stone's r-b),
> > does that one not work?
> >
> Not when in cloned mode.
>
> 2 connectors on same crtc.
>
> Update dpms property to off connector 1, commit. update_legacy_modeset_state
> will reset it to DPMS_ON.
> Update dpms property to off on connector 2, commit.
> update_legacy_modeset_state will reset it to DPMS_ON.
>
> Expected result: DPMS on the screen is OFF
> Actual result: ON with i915.
Ok this definitely needs a comment plus better commit message somewhere
since obviously I understood it only now. I'll drop my patch.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 01/13] drm/atomic: Only update crtc->x/y if it's part of the state.
On Thu, Jul 16, 2015 at 11:17:29AM +0200, Maarten Lankhorst wrote:
> Op 16-07-15 om 11:19 schreef Daniel Vetter:
> > On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst wrote:
> >> Cc: dri-devel at lists.freedesktop.org
> >> Signed-off-by: Maarten Lankhorst
> >> ---
> >> drivers/gpu/drm/drm_atomic_helper.c | 7 +--
> >> 1 file changed, 5 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >> b/drivers/gpu/drm/drm_atomic_helper.c
> >> index 0898afbc9e23..70e69904291d 100644
> >> --- a/drivers/gpu/drm/drm_atomic_helper.c
> >> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> >> @@ -667,8 +667,11 @@ drm_atomic_helper_update_legacy_modeset_state(struct
> >> drm_device *dev,
> >>for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> >>crtc->mode = crtc->state->mode;
> >>crtc->enabled = crtc->state->enable;
> >> - crtc->x = crtc->primary->state->src_x >> 16;
> >> - crtc->y = crtc->primary->state->src_y >> 16;
> >> +
> >> + if (drm_atomic_get_existing_plane_state(old_state,
> >> crtc->primary)) {
> >> + crtc->x = crtc->primary->state->src_x >> 16;
> >> + crtc->y = crtc->primary->state->src_y >> 16;
> >> + }
> > What's the benefit here of only updating when something changed? The
> > atomic state should be the master source so copying a few too many times
> > shouldn't matter really.
> Because you might not be holding plane lock, so primary->state may be garbage.
Anyone who wants to touch primary plane must grab the crtc lock, so crtc
lock would give you an implicit read lock. At least that's been my
thinking, but it could be that the primary plane is used on some other
crtc, and then this is indeed garbage.
So maybe we need even more checks than what you propose:
if (drm_atomic_get_existing_plane_state(old_state, crtc->primary) &&
crtc->primary->state->crtc == crtc) {
crtc->x = crtc->primary->state->src_x >> 16;
crtc->y = crtc->primary->state->src_y >> 16;
}
I think a comment explaining this would help (or at least in the commit
message!).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 02/13] drm/atomic: Update legacy DPMS state during modesets.
Op 16-07-15 om 11:19 schreef Daniel Vetter:
> On Thu, Jul 16, 2015 at 10:59:15AM +0200, Maarten Lankhorst wrote:
>> This is required for DPMS to work correctly, during a modeset
>> the DPMS property should be turned off, unless the crtc
>> is made active in which case it should be set to DPMS on.
>>
>> Cc: dri-devel at lists.freedesktop.org
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/drm_atomic_helper.c | 16 ++--
>> 1 file changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 70e69904291d..cdec643971a2 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -642,6 +642,12 @@ drm_atomic_helper_update_legacy_modeset_state(struct
>> drm_device *dev,
>>
>> /* clear out existing links */
>> for_each_connector_in_state(old_state, connector, old_conn_state, i) {
>> +struct drm_crtc *crtc = connector->state->crtc;
>> +
>> +if (crtc &&
>> +drm_atomic_crtc_needs_modeset(crtc->state))
>> +connector->dpms = DRM_MODE_DPMS_OFF;
> Same here, why only update when something changed? I already applied my
> patch from yesterday which updates this always (with Daniel Stone's r-b),
> does that one not work?
>
Not when in cloned mode.
2 connectors on same crtc.
Update dpms property to off connector 1, commit. update_legacy_modeset_state
will reset it to DPMS_ON.
Update dpms property to off on connector 2, commit. update_legacy_modeset_state
will reset it to DPMS_ON.
Expected result: DPMS on the screen is OFF
Actual result: ON with i915.
[PATCH 02/13] drm/atomic: Update legacy DPMS state during modesets.
On Thu, Jul 16, 2015 at 10:59:15AM +0200, Maarten Lankhorst wrote:
> This is required for DPMS to work correctly, during a modeset
> the DPMS property should be turned off, unless the crtc
> is made active in which case it should be set to DPMS on.
>
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 16 ++--
> 1 file changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 70e69904291d..cdec643971a2 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -642,6 +642,12 @@ drm_atomic_helper_update_legacy_modeset_state(struct
> drm_device *dev,
>
> /* clear out existing links */
> for_each_connector_in_state(old_state, connector, old_conn_state, i) {
> + struct drm_crtc *crtc = connector->state->crtc;
> +
> + if (crtc &&
> + drm_atomic_crtc_needs_modeset(crtc->state))
> + connector->dpms = DRM_MODE_DPMS_OFF;
Same here, why only update when something changed? I already applied my
patch from yesterday which updates this always (with Daniel Stone's r-b),
does that one not work?
-Daniel
> +
> if (!connector->encoder)
> continue;
>
> @@ -653,14 +659,20 @@ drm_atomic_helper_update_legacy_modeset_state(struct
> drm_device *dev,
>
> /* set new links */
> for_each_connector_in_state(old_state, connector, old_conn_state, i) {
> - if (!connector->state->crtc)
> + struct drm_crtc *crtc = connector->state->crtc;
> +
> + if (!crtc)
> continue;
>
> + if (crtc->state->active &&
> + drm_atomic_crtc_needs_modeset(crtc->state))
> + connector->dpms = DRM_MODE_DPMS_ON;
> +
> if (WARN_ON(!connector->state->best_encoder))
> continue;
>
> connector->encoder = connector->state->best_encoder;
> - connector->encoder->crtc = connector->state->crtc;
> + connector->encoder->crtc = crtc;
> }
>
> /* set legacy state in the crtc structure */
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 01/13] drm/atomic: Only update crtc->x/y if it's part of the state.
On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst wrote:
> Cc: dri-devel at lists.freedesktop.org
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 0898afbc9e23..70e69904291d 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -667,8 +667,11 @@ drm_atomic_helper_update_legacy_modeset_state(struct
> drm_device *dev,
> for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
> crtc->mode = crtc->state->mode;
> crtc->enabled = crtc->state->enable;
> - crtc->x = crtc->primary->state->src_x >> 16;
> - crtc->y = crtc->primary->state->src_y >> 16;
> +
> + if (drm_atomic_get_existing_plane_state(old_state,
> crtc->primary)) {
> + crtc->x = crtc->primary->state->src_x >> 16;
> + crtc->y = crtc->primary->state->src_y >> 16;
> + }
What's the benefit here of only updating when something changed? The
atomic state should be the master source so copying a few too many times
shouldn't matter really.
-Daniel
>
> if (crtc->state->enable)
> drm_calc_timestamping_constants(crtc,
> --
> 2.1.0
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[PATCH 01/13] drm/atomic: Only update crtc->x/y if it's part of the state.
Op 16-07-15 om 11:19 schreef Daniel Vetter:
> On Thu, Jul 16, 2015 at 10:59:14AM +0200, Maarten Lankhorst wrote:
>> Cc: dri-devel at lists.freedesktop.org
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/drm_atomic_helper.c | 7 +--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 0898afbc9e23..70e69904291d 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -667,8 +667,11 @@ drm_atomic_helper_update_legacy_modeset_state(struct
>> drm_device *dev,
>> for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
>> crtc->mode = crtc->state->mode;
>> crtc->enabled = crtc->state->enable;
>> -crtc->x = crtc->primary->state->src_x >> 16;
>> -crtc->y = crtc->primary->state->src_y >> 16;
>> +
>> +if (drm_atomic_get_existing_plane_state(old_state,
>> crtc->primary)) {
>> +crtc->x = crtc->primary->state->src_x >> 16;
>> +crtc->y = crtc->primary->state->src_y >> 16;
>> +}
> What's the benefit here of only updating when something changed? The
> atomic state should be the master source so copying a few too many times
> shouldn't matter really.
Because you might not be holding plane lock, so primary->state may be garbage.
~Maarten
[PATCH v9 2/4] drm/panel: simple: Add support for NEC NL4827HC19-05B 480x272 panel
> -Original Message-
> From: Thierry Reding [mailto:thierry.reding at gmail.com]
> Sent: Tuesday, July 14, 2015 6:54 PM
> To: Wang Jianwei-B52261
> Cc: dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org;
> linux-
> arm-kernel at lists.infradead.org; devicetree at vger.kernel.org;
> airlied at linux.ie; daniel.vetter at ffwll.ch; mark.yao at rock-chips.com;
> Wood
> Scott-B07421; Wang Huan-B18965; Xiubo Li
> Subject: Re: [PATCH v9 2/4] drm/panel: simple: Add support for NEC
> NL4827HC19-05B 480x272 panel
>
> On Mon, Jul 13, 2015 at 06:51:30PM +0800, Jianwei Wang wrote:
> > This adds support for the NEC NL4827HC19-05B 480x272 panel to the DRM
> > simple panel driver.
> >
> > Signed-off-by: Alison Wang
> > Signed-off-by: Xiubo Li
> > Signed-off-by: Jianwei Wang
> > Acked-by: Daniel Vetter
> > ---
> > .../bindings/panel/nec,nl4827hc19_05b.txt | 7 ++
> > .../devicetree/bindings/vendor-prefixes.txt| 1 +
> > MAINTAINERS| 1 -
> > drivers/gpu/drm/panel/panel-simple.c | 26
> ++
> > 4 files changed, 34 insertions(+), 1 deletion(-) create mode 100644
> > Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
> >
> > diff --git
> > a/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
> > b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
> > new file mode 100644
> > index 000..20e9473
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
> > @@ -0,0 +1,7 @@
> > +NEC LCD Technologies,Ltd. WQVGA TFT LCD panel
> > +
> > +Required properties:
> > +- compatible: should be "nec,nl4827hc19_05b"
> > +
> > +This binding is compatible with the simple-panel binding, which is
> > +specified in simple-panel.txt in this directory.
> > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > index 8033919..9f22b3e 100644
> > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt
> > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
> > @@ -131,6 +131,7 @@ mundoreader Mundo Reader S.L.
> > murata Murata Manufacturing Co., Ltd.
> > mxicy Macronix International Co., Ltd.
> > national National Semiconductor
> > +necNEC LCD Technologies, Ltd.
> > neonodeNeonode Inc.
> > netgearNETGEAR
> > netlogic Broadcom Corporation (formerly NetLogic Microsystems)
>
> This belongs in a separate patch.
>
Ok!
> > diff --git a/MAINTAINERS b/MAINTAINERS index fffb8c9..e191ded 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -3410,7 +3410,6 @@ M:Alison Wang
> > L: dri-devel at lists.freedesktop.org
> > S: Supported
> > F: drivers/gpu/drm/fsl-dcu/
> > -F: Documentation/devicetree/bindings/drm/fsl-dcu/
>
> What's this doing here?
>
It's a mistake. I must be very careful next time.
> > F: Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt
> >
> > DRM DRIVERS FOR NVIDIA TEGRA
> > diff --git a/drivers/gpu/drm/panel/panel-simple.c
> > b/drivers/gpu/drm/panel/panel-simple.c
> > index f94201b..eb12fe4 100644
> > --- a/drivers/gpu/drm/panel/panel-simple.c
> > +++ b/drivers/gpu/drm/panel/panel-simple.c
> > @@ -1036,6 +1036,29 @@ static const struct panel_desc
> shelly_sca07010_bfn_lnn = {
> > .bus_format = MEDIA_BUS_FMT_RGB666_1X18, };
> >
> > +static const struct drm_display_mode nec_nl4827hc19_05b_mode = {
> > + .clock = 10870,
> > + .hdisplay = 480,
> > + .hsync_start = 480 + 2,
> > + .hsync_end = 480 + 2 + 41,
> > + .htotal = 480 + 2 + 41 + 2,
> > + .vdisplay = 272,
> > + .vsync_start = 272 + 2,
> > + .vsync_end = 272 + 2 + 4,
> > + .vtotal = 272 + 2 + 4 + 2,
> > + .vrefresh = 74,
> > +};
> > +
> > +static const struct panel_desc nec_nl4827hc19_05b = {
> > + .modes = &nec_nl4827hc19_05b_mode,
> > + .num_modes = 1,
> > + .size = {
> > + .width = 95,
> > + .height = 54,
> > + },
> > + .bus_format = MEDIA_BUS_FMT_RGB888_1X24 };
> > +
>
> Please keep these...
>
> > static const struct of_device_id platform_of_match[] = {
> > {
> > .compatible = "ampire,am800480r3tmqwa1h", @@ -1125,6 +1148,9
> @@
> > static const struct of_device_id platform_of_match[] = {
> > .compatible = "shelly,sca07010-bfn-lnn",
> > .data = &shelly_sca07010_bfn_lnn,
> > }, {
> > + .compatible = "nec,nl4827hc19_05b",
> > + .data = &nec_nl4827hc19_05b,
> > + }, {
>
> and this sorted alphabetically.
>
> Thierry
Ok!
Thanks for your guidance
Jianwei
[PATCH v9 1/4] drm/layerscape: Add Freescale DCU DRM driver
Hi Thierry, Thank you very much for your patient and careful guidance. I'm updating my driver according to your comments. > -Original Message- > From: Thierry Reding [mailto:thierry.reding at gmail.com] > Sent: Tuesday, July 14, 2015 6:49 PM > To: Wang Jianwei-B52261 > Cc: dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org; > linux- > arm-kernel at lists.infradead.org; devicetree at vger.kernel.org; > airlied at linux.ie; daniel.vetter at ffwll.ch; mark.yao at rock-chips.com; > Wood > Scott-B07421; Wang Huan-B18965; Xiubo Li; Wang Jianwei-B52261 > Subject: Re: [PATCH v9 1/4] drm/layerscape: Add Freescale DCU DRM driver > > On Mon, Jul 13, 2015 at 06:51:29PM +0800, Jianwei Wang wrote: > > This patch add support for Two Dimensional Animation and Compositing > > Engine (2D-ACE) on the Freescale SoCs. > > > > 2D-ACE is a Freescale display controller. 2D-ACE describes the > > functionality of the module extremely well its name is a value that > > cannot be used as a token in programming languages. > > Instead the valid token "DCU" is used to tag the register names and > > function names. > > > > The Display Controller Unit (DCU) module is a system master that > > fetches graphics stored in internal or external memory and displays > > them on a TFT LCD panel. A wide range of panel sizes is supported and > > the timing of the interface signals is highly configurable. > > Graphics are read directly from memory and then blended in real-time, > > which allows for dynamic content creation with minimal CPU > > intervention. > > Is this for some non-i.MX SoC? Yes. Ls1021a and i.MX use different video IP modules. > > > The features: > > (1) Full RGB888 output to TFT LCD panel. > > (2) For the current LCD panel, WQVGA "480x272" is supported. > > Would be more useful to describe the actual capabilities of the display > controller rather than what's supported by the panel that you happened to > have attached to it. Ok, I'll remove it > > > (3) Blending of each pixel using up to 4 source layers dependent on > > size of panel. > > (4) Each graphic layer can be placed with one pixel resolution in > > either axis. > > (5) Each graphic layer support RGB565 and RGB888 direct colors without > > alpha channel and BGRA BGRA ARGB1555 direct colors with an > > alpha channel and YUV422 format. > > (6) Each graphic layer support alpha blending with 8-bit resolution. > > > > This is a simplified version, only one primary plane, one framebuffer, > > one crtc, one connector and one encoder for TFT LCD panel. > > > > Signed-off-by: Alison Wang > > Signed-off-by: Xiubo Li > > Signed-off-by: Jianwei Wang > > Acked-by: Daniel Vetter > > Reviewed-by: Alison Wang > [...] > > diff --git a/MAINTAINERS b/MAINTAINERS index 6761318..fffb8c9 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -3404,6 +3404,15 @@ S: Maintained > > F: drivers/gpu/drm/imx/ > > F: Documentation/devicetree/bindings/drm/imx/ > > > > +DRM DRIVERS FOR FREESCALE DCU > > +M: Jianwei Wang > > +M: Alison Wang > > +L: dri-devel at lists.freedesktop.org > > +S: Supported > > +F: drivers/gpu/drm/fsl-dcu/ > > +F: Documentation/devicetree/bindings/drm/fsl-dcu/ > > +F: Documentation/devicetree/bindings/panel/nec,nl4827hc19_05b.txt > > This binding has got nothing to do with the display driver, so it > shouldn't be listed here. > > Also, please use tabs consistently (the above two lines use spaces). Sorry, I made this mistake when formatting patches. I'll be more careful next time. > > > DRM DRIVERS FOR NVIDIA TEGRA > > M: Thierry Reding > > M: Terje Bergström > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig index > > c46ca31..9cfd14e 100644 > > --- a/drivers/gpu/drm/Kconfig > > +++ b/drivers/gpu/drm/Kconfig > > @@ -231,6 +231,8 @@ source "drivers/gpu/drm/virtio/Kconfig" > > > > source "drivers/gpu/drm/msm/Kconfig" > > > > +source "drivers/gpu/drm/fsl-dcu/Kconfig" > > + > > As mentioned in a different email, I'm somewhat annoyed by the random > placement of these source statements. But we can probably clean that up in > one go and insist on proper ordering when there is one. > Ok, I plan to move it to the last line. Is it ok? > > diff --git a/drivers/gpu/drm/fsl-dcu/Makefile > > b/drivers/gpu/drm/fsl-dcu/Makefile > > new file mode 100644 > > index 000..336b4a6 > > --- /dev/null > > +++ b/drivers/gpu/drm/fsl-dcu/Makefile > > @@ -0,0 +1,7 @@ > > +fsl-dcu-drm-y := fsl_dcu_drm_drv.o \ > > + fsl_dcu_drm_kms.o \ > > + fsl_dcu_drm_connector.o \ > > + fsl_dcu_drm_plane.o \ > > + fsl_dcu_drm_crtc.o \ > > + fsl_dcu_drm_fbdev.o > > I don't get what kind of indentation this is supposed to be. Either align > everything with the first object file, or use a single tab rather than a > tab followed by a couple of spaces. > OK! > > +obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu-drm.o > > diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_connector
[PATCH] drm: rcar-du: Add dependency to OF
On Thu, Jul 16, 2015 at 10:44 AM, Laurent Pinchart
wrote:
> The driver requires OF support, add a dependency in Kconfig and remove
> the platform_device_id table that isn't used anymore.
>
> Signed-off-by: Laurent Pinchart
Once Simon has queued up the removal of board-marzen.c:
Acked-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at
linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH 02/13] drm/atomic: Update legacy DPMS state during modesets.
This is required for DPMS to work correctly, during a modeset
the DPMS property should be turned off, unless the crtc
is made active in which case it should be set to DPMS on.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 70e69904291d..cdec643971a2 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -642,6 +642,12 @@ drm_atomic_helper_update_legacy_modeset_state(struct
drm_device *dev,
/* clear out existing links */
for_each_connector_in_state(old_state, connector, old_conn_state, i) {
+ struct drm_crtc *crtc = connector->state->crtc;
+
+ if (crtc &&
+ drm_atomic_crtc_needs_modeset(crtc->state))
+ connector->dpms = DRM_MODE_DPMS_OFF;
+
if (!connector->encoder)
continue;
@@ -653,14 +659,20 @@ drm_atomic_helper_update_legacy_modeset_state(struct
drm_device *dev,
/* set new links */
for_each_connector_in_state(old_state, connector, old_conn_state, i) {
- if (!connector->state->crtc)
+ struct drm_crtc *crtc = connector->state->crtc;
+
+ if (!crtc)
continue;
+ if (crtc->state->active &&
+ drm_atomic_crtc_needs_modeset(crtc->state))
+ connector->dpms = DRM_MODE_DPMS_ON;
+
if (WARN_ON(!connector->state->best_encoder))
continue;
connector->encoder = connector->state->best_encoder;
- connector->encoder->crtc = connector->state->crtc;
+ connector->encoder->crtc = crtc;
}
/* set legacy state in the crtc structure */
--
2.1.0
[PATCH 01/13] drm/atomic: Only update crtc->x/y if it's part of the state.
Cc: dri-devel at lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 0898afbc9e23..70e69904291d 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -667,8 +667,11 @@ drm_atomic_helper_update_legacy_modeset_state(struct
drm_device *dev,
for_each_crtc_in_state(old_state, crtc, old_crtc_state, i) {
crtc->mode = crtc->state->mode;
crtc->enabled = crtc->state->enable;
- crtc->x = crtc->primary->state->src_x >> 16;
- crtc->y = crtc->primary->state->src_y >> 16;
+
+ if (drm_atomic_get_existing_plane_state(old_state,
crtc->primary)) {
+ crtc->x = crtc->primary->state->src_x >> 16;
+ crtc->y = crtc->primary->state->src_y >> 16;
+ }
if (crtc->state->enable)
drm_calc_timestamping_constants(crtc,
--
2.1.0
[PATCH] drm/fbdev: Return -EBUSY when oopsing
Trying to do anything with kms drivers when oopsing has become a
failing proposition. But since we can end up in the fbdev code simply
due to the console unblanking that's done unconditionally just
removing our panic handler isn't enough. We need to block all fbdev
callbacks when oopsing.
There was already one in the blank handler, but it failed silently.
That makes it impossible for drivers (like i915) who subclass these
functions to figure this out.
Instead consistently return -EBUSY so that everyone knows that we
really don't want to be bothered right now. This also allows us to
remove a pile of FIXMEs from the i915 fbdev code (since due to the
failure code they now won't attempt to grab dangerous locks any more).
Cc: Dave Airlie
Cc: Rodrigo Vivi
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c| 24
drivers/gpu/drm/i915/intel_fbdev.c | 21 -
2 files changed, 12 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index 329d08167b77..22056d0807bb 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -509,14 +509,6 @@ static void drm_fb_helper_dpms(struct fb_info *info, int
dpms_mode)
int i, j;
/*
-* fbdev->blank can be called from irq context in case of a panic.
-* Since we already have our own special panic handler which will
-* restore the fbdev console mode completely, just bail out early.
-*/
- if (oops_in_progress)
- return;
-
- /*
* For each CRTC in this fb, turn the connectors on/off.
*/
drm_modeset_lock_all(dev);
@@ -549,6 +541,9 @@ static void drm_fb_helper_dpms(struct fb_info *info, int
dpms_mode)
*/
int drm_fb_helper_blank(int blank, struct fb_info *info)
{
+ if (oops_in_progress)
+ return -EBUSY;
+
switch (blank) {
/* Display: On; HSync: On, VSync: On */
case FB_BLANK_UNBLANK:
@@ -776,9 +771,10 @@ int drm_fb_helper_setcmap(struct fb_cmap *cmap, struct
fb_info *info)
int i, j, rc = 0;
int start;
- if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
+ if (oops_in_progress)
return -EBUSY;
- }
+
+ drm_modeset_lock_all(dev);
if (!drm_fb_helper_is_bound(fb_helper)) {
drm_modeset_unlock_all(dev);
return -EBUSY;
@@ -927,6 +923,9 @@ int drm_fb_helper_set_par(struct fb_info *info)
struct drm_fb_helper *fb_helper = info->par;
struct fb_var_screeninfo *var = &info->var;
+ if (oops_in_progress)
+ return -EBUSY;
+
if (var->pixclock != 0) {
DRM_ERROR("PIXEL CLOCK SET\n");
return -EINVAL;
@@ -952,9 +951,10 @@ int drm_fb_helper_pan_display(struct fb_var_screeninfo
*var,
int ret = 0;
int i;
- if (__drm_modeset_lock_all(dev, !!oops_in_progress)) {
+ if (oops_in_progress)
return -EBUSY;
- }
+
+ drm_modeset_lock_all(dev);
if (!drm_fb_helper_is_bound(fb_helper)) {
drm_modeset_unlock_all(dev);
return -EBUSY;
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index eef54feb7545..b763f24e20ef 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -55,13 +55,6 @@ static int intel_fbdev_set_par(struct fb_info *info)
ret = drm_fb_helper_set_par(info);
if (ret == 0) {
- /*
-* FIXME: fbdev presumes that all callbacks also work from
-* atomic contexts and relies on that for emergency oops
-* printing. KMS totally doesn't do that and the locking here is
-* by far not the only place this goes wrong. Ignore this for
-* now until we solve this for real.
-*/
mutex_lock(&fb_helper->dev->struct_mutex);
intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
mutex_unlock(&fb_helper->dev->struct_mutex);
@@ -80,13 +73,6 @@ static int intel_fbdev_blank(int blank, struct fb_info *info)
ret = drm_fb_helper_blank(blank, info);
if (ret == 0) {
- /*
-* FIXME: fbdev presumes that all callbacks also work from
-* atomic contexts and relies on that for emergency oops
-* printing. KMS totally doesn't do that and the locking here is
-* by far not the only place this goes wrong. Ignore this for
-* now until we solve this for real.
-*/
mutex_lock(&fb_helper->dev->struct_mutex);
intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
mutex_unlock(&fb_helper->dev->struct_mutex);
@@ -106,13 +92,6 @@ static int intel_fbdev_pan_display(struct fb_var_screeninfo
[RFC PATCH] drm/fb: drop panic handling
On Thu, Jul 09, 2015 at 11:14:43PM +0200, Daniel Vetter wrote:
> On Thu, Jul 09, 2015 at 01:15:34PM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > This really doesn't seem to have much chance of working anymore,
> >
> > esp for irq context, qxl at least tries to talk to the hw,
> > and waits for irqs, and fails.
> >
> > with runtime pm and other stuff I think we should just
> > bail on this for now.
> >
> > Signed-off-by: Dave Airlie
>
> Yeah concurred that this has become hopeless. Also this would allow us to
> drop an pretension in i915 to still support this which means we can stop
> checking drm_can_sleep in our wait_for macros. Which has papered over some
> pretty serious bugs.
>
> Reviewed-by: Daniel Vetter
Well I applied this to drm-misc.
> There's one more though, we can get into the fbdev callbacks through a
> pretty impressive chain:
>
> panic() -> bust_spinlock() -> console_unblank() -> pass the trylock ->
> c->unblank() -> unblank_screen() (now in vt/vt.c) ->
> vc_sw->con_blank() -> fbcon_blank()
>
> To make this really complete I think we also need to sprinkle
>
> if (oops_in_progress)
> return;
>
> over all the fbdev entry points we have in drm_fbdev_helper.c plus all the
> ones in drivers which have their own (qxl, udl, i915 are the ones I know
> of).
I'll do a patch for this. Just realized that we have some cargo-culted
checks already, but they don't work everywhere so mostly about unifying
everything.
-Daniel
>
> Cheers, Daniel
>
> > ---
> > drivers/gpu/drm/drm_fb_helper.c | 26 --
> > 1 file changed, 26 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index cac4229..eaf652b 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -429,24 +429,6 @@ static bool drm_fb_helper_force_kernel_mode(void)
> > return error;
> > }
> >
> > -static int drm_fb_helper_panic(struct notifier_block *n, unsigned long
> > ununsed,
> > - void *panic_str)
> > -{
> > - /*
> > -* It's a waste of time and effort to switch back to text console
> > -* if the kernel should reboot before panic messages can be seen.
> > -*/
> > - if (panic_timeout < 0)
> > - return 0;
> > -
> > - pr_err("panic occurred, switching back to text console\n");
> > - return drm_fb_helper_force_kernel_mode();
> > -}
> > -
> > -static struct notifier_block paniced = {
> > - .notifier_call = drm_fb_helper_panic,
> > -};
> > -
> > static bool drm_fb_helper_is_bound(struct drm_fb_helper *fb_helper)
> > {
> > struct drm_device *dev = fb_helper->dev;
> > @@ -672,9 +654,6 @@ void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
> > if (!list_empty(&fb_helper->kernel_fb_list)) {
> > list_del(&fb_helper->kernel_fb_list);
> > if (list_empty(&kernel_fb_helper_list)) {
> > - pr_info("drm: unregistered panic notifier\n");
> > - atomic_notifier_chain_unregister(&panic_notifier_list,
> > -&paniced);
> > unregister_sysrq_key('v',
> > &sysrq_drm_fb_helper_restore_op);
> > }
> > }
> > @@ -1109,12 +1088,7 @@ static int drm_fb_helper_single_fb_probe(struct
> > drm_fb_helper *fb_helper,
> > dev_info(fb_helper->dev->dev, "fb%d: %s frame buffer device\n",
> > info->node, info->fix.id);
> >
> > - /* Switch back to kernel console on panic */
> > - /* multi card linked list maybe */
> > if (list_empty(&kernel_fb_helper_list)) {
> > - dev_info(fb_helper->dev->dev, "registered panic notifier\n");
> > - atomic_notifier_chain_register(&panic_notifier_list,
> > - &paniced);
> > register_sysrq_key('v', &sysrq_drm_fb_helper_restore_op);
> > }
> >
> > --
> > 2.4.3
> >
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
[Bug 99041] HDMI Audio not working after fixing HDMI.
https://bugzilla.kernel.org/show_bug.cgi?id=99041 --- Comment #1 from Florent Le Coz --- The issue is still present on kernel 4.0.7. Little precision, that may be useful to diagnose the problem: - If I boot with that HDMI-connected screen turned off and then I turn it on with my X session already fully started, it is not automatically detected (the screen says âno signalâ), but this used to work on older versions of linux (canât remember which one introduced this âregressionâ). Next, if I manually configure it with that command: xrandr --output DVI-0 --mode 1920x1080 --output DVI-1 --right-of DVI-0 --mode 1920x1080 --output HDMI-0 --right-of DVI-1 --mode 1920x1080 the image on the screen works, but not the sound. - However, if I boot while that screen is already turned on (or if I turn it on while still on the gdm login screen), it is automatically detected and both the image AND the sound BOTH work immediately. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 1/1] drm/sti: fix master bind bug for using component
This patch isn't the good one, I send the fix here: http://lists.freedesktop.org/archives/dri-devel/2015-July/086568.html Regards, Benjamin 2015-07-16 3:13 GMT+02:00 Xinwei Kong : > Thank you for Russel. > > It is Right, when this sti_tvout (component) finish executing component > ".bind" > function while sti_hdmi or sti_hda is not registered. the bug will occur . > > this patch will prepare this bug by calling master .bind of sti_tvout after > sti_hdmi or sti_hda is register to finish binding sti_hdmi or sti_hda > component, > however, it also slove to bring the "drm_dev" struct into the sti_hdmi or > sti_hda. > > Thank you > Xinwei > > On 2015/7/15 21:17, Benjamin Gaignard wrote: >> Thanks a lot Russell, I have now understand where was my mistake. >> >> >> 2015-07-15 12:42 GMT+02:00 Russell King - ARM Linux > arm.linux.org.uk>: >>> On Wed, Jul 15, 2015 at 12:19:01PM +0200, Benjamin Gaignard wrote: The build order in Makefile hasn't been change so the bug doesn't occur... In addition of taking care of not changing build order in Makefile, I would like to understand what is the expected behavior of component framework when master call component_bind_all() before any component_add() calls. Should component bind function be called in component_add() ? Is up to component to detect that master is already bounded ? Russell can you tell us what to do in this case ? >>> >>> I don't follow, and you certainly should never get into the situation >>> you're alluding to (where the master is already bound but a component >>> is not.) >>> >>> The way this should work is: >>> >>> - master and components register themselves into the component helper >>> in a random order. >>> - when the master registers, it gives the component helper a set of >>> matches which it uses to determine which components are required. >>> - when the component helper determines that all components and the >>> master have been registered, it calls the master bind function. >>> - the master bind function is responsible for the classical subsystem >>> initialisation, calling component_bind_all() to cause the individual >>> components bind() method to be called. >>> >>> So, you should never _ever_ be in the situation where initcall ordering >>> matters, or where the master is already bound but a component hasn't >>> registered. >>> >>> -- >>> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up >>> according to speedtest.net. >> >> >> > -- Benjamin Gaignard Graphic Working Group Linaro.org â Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
[PATCH 1/1] drm/sti: fix master bind bug for using component
Thank you for Russel. It is Right, when this sti_tvout (component) finish executing component ".bind" function while sti_hdmi or sti_hda is not registered. the bug will occur . this patch will prepare this bug by calling master .bind of sti_tvout after sti_hdmi or sti_hda is register to finish binding sti_hdmi or sti_hda component, however, it also slove to bring the "drm_dev" struct into the sti_hdmi or sti_hda. Thank you Xinwei On 2015/7/15 21:17, Benjamin Gaignard wrote: > Thanks a lot Russell, I have now understand where was my mistake. > > > 2015-07-15 12:42 GMT+02:00 Russell King - ARM Linux arm.linux.org.uk>: >> On Wed, Jul 15, 2015 at 12:19:01PM +0200, Benjamin Gaignard wrote: >>> The build order in Makefile hasn't been change so the bug doesn't occur... >>> >>> In addition of taking care of not changing build order in Makefile, >>> I would like to understand what is the expected behavior of component >>> framework when >>> master call component_bind_all() before any component_add() calls. >>> >>> Should component bind function be called in component_add() ? >>> Is up to component to detect that master is already bounded ? >>> >>> Russell can you tell us what to do in this case ? >> >> I don't follow, and you certainly should never get into the situation >> you're alluding to (where the master is already bound but a component >> is not.) >> >> The way this should work is: >> >> - master and components register themselves into the component helper >> in a random order. >> - when the master registers, it gives the component helper a set of >> matches which it uses to determine which components are required. >> - when the component helper determines that all components and the >> master have been registered, it calls the master bind function. >> - the master bind function is responsible for the classical subsystem >> initialisation, calling component_bind_all() to cause the individual >> components bind() method to be called. >> >> So, you should never _ever_ be in the situation where initcall ordering >> matters, or where the master is already bound but a component hasn't >> registered. >> >> -- >> FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up >> according to speedtest.net. > > >
[PATCH] drm/atomic-helper: Also update legacy dpms state
On Wed, Jul 15, 2015 at 04:48:33PM +0100, Daniel Stone wrote: > On 15 July 2015 at 16:44, Daniel Vetter wrote: > > Avoids legacy userspace/code getting confused when dpms doesn't > > reflect reality of what's going on. > > > > Signed-off-by: Daniel Vetter > > Reviewed-by: Daniel Stone Applied to drm-misc, thanks for the review. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
[PULL] topic/drm-fixes
Hi Dave, Ok next attempt at drm-fixes pull. Big thing really is just the compat32 one for addfb2.1. Cheers, Daniel The following changes since commit e24ff467e12e1560de753313976c46e84fa6306a: drm/crtc: Fix edid length computation (2015-07-04 00:52:34 +0200) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-fixes-2015-07-16 for you to fetch changes up to c631d5f90e7ee246536c72f80ade86e9ef4d2f13: drm: Provide compat ioctl for addfb2.1 (2015-07-15 11:38:38 +0200) Daniel Kurtz (1): drm/rockchip: use drm_gem_mmap helpers Graham Whaley (1): Documentation: drm: Fix tablulation in KMS properties table Tvrtko Ursulin (1): drm: Provide compat ioctl for addfb2.1 Zhao Junwang (1): drm: add a check for x/y in drm_mode_setcrtc Documentation/DocBook/drm.tmpl | 2 +- drivers/gpu/drm/drm_crtc.c | 7 ++- drivers/gpu/drm/drm_ioc32.c | 60 ++ drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 67 +++-- 4 files changed, 100 insertions(+), 36 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
test
test -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/eed71639/attachment-0001.html>
[Bug 91268] R6xx freezes with kernel 3.17 and up
https://bugs.freedesktop.org/show_bug.cgi?id=91268 --- Comment #9 from Michel Dänzer --- (In reply to Kajzer from comment #8) > I suspect you need one when hang happens, No, as I said I'm mostly interested in the initialization messages. > I'm trying really hard to make it hang with the patch from Alex but it seems > that patch did the trick, there are no more hangs. That's expected. Alex's patch isn't a fix but just to confirm the problem is really directly related to write-combined CPU mappings. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150716/dacf1e28/attachment-0001.html>
