[Bug 84944] tearing on radeonsi vdpau deinterlacer
https://bugs.freedesktop.org/show_bug.cgi?id=84944 --- Comment #21 from Michel D?nzer --- (In reply to warpme from comment #20) > [1031252.040] DRI2CanFlip: Window clipList doesn\'t match root window > dimensions: > [1031252.040] Window clipList extents: (0, 0)-(1920, 1078) > [1031252.040] Root window extents: (0, 0)-(1920, 1080) Looks like either the MythTV output window is only 1078 pixels high, or the bottom two rows of it are covered by another window. Can you run xwininfo while there is tearing in MythTV, click on the MythTV output window, and provide the output from xwininfo? -- 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/20141024/0d51dffb/attachment.html>
tile property contents
>> > > There are also configurations where users configure multiple heads to >> > > drive power walls that they want to be treated as one logical monitor, >> > > similar to the DP MST tiled display case. Normally, those powerwall >> > > configurations don't have any layout information from the monitors >> > > themselves, and the layout is configured by the user. >> > > >> > > Would it be appropriate for users to be able to set the TILE property >> > > in that sort of scenario? >> > > >> > > For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc >> > > should be expressed in pixels rather than tiles? Sometimes, the tiles >> > > in those powerwalls may not all have the same resolution, or may be >> > > configured with overlap. I suppose that would make the TILE >> > > configuration >> > > specific to the current modetimings on each tile... >> > >> > Why can't users just set that mode? >> >> Sure, users can set the mode, but: >> >> * Part of what the TILE property conveys is how monitors should be grouped >> for purposes of window maximization. Users don't have a great way to >> express that today, that I'm aware of. > > My understanding for why we want the TILE property is to avoid to > duplicate displayId parsing over every bit of userspace (and the fbcon > stuff in the kernel) interested in it. Imo the proper way for userspace is > to always just inherit whatever modeset config is already there. Andy's idea is good, I'd considered it before, the problem being how to expose it nicely, not sure if you'd want persistent via /sys or dynamic setting of the property by user for that session, so we could do it like xrandr modes. Daniel you are missing the nice case of using TILE for non-displayid monitors once the infrastructure is in place. Having it so you can create user defined tile groups to allow users to configure arbitrary walls is a useful thing, that you can't do any other way. > >> * Users might configure the mode they want, but then gnome-settings-daemon >> may come along later and decide it knows better than the user how things >> should be configured. One scenario where this comes up is: >> (a) user meticulously configures his power wall >> (b) user hotplugs another monitor >> I've definitely seen cases where window managers will try to be clever >> in response to a hotplug, and clobber the user's current configuration. >> If the TILE property conveyed how some set of monitors was supposed >> to be grouped, that would hopefully give window managers additional >> information, such that they would know to keep that group intact. > > Well, imnsho gnome display control center is a bit too opiniated about > automatic modeset changes. If their assumption is that they always know > perfectly what the user wants upon hotplug I really don't want to work > around this in the kernel. Since for everything else than a laptop + > beamer gnome panel always pisses me off ;-) > > I think gnome should just ask the user what it wants if there's more than > 2 physical displays (treating a tiled 4k screen as one ofc), since there's > really no way at all to tell. Well its not just a GNOME problem either, once things like SDL respect tIle properrty, we can create arbitary tile walls that the whole stack will respect, instead of hacks like fake xinerama. Dave.
[Bug 75011] [hyperz] Performance drop since git-01e6371 (disable hyperz by default) with radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75011 Andreas Boll changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Andreas Boll --- Fixed with commit 14bdcc6ff98664552216acfdb7e35d0b128003ef Author: Andreas Boll Date: Thu Oct 23 14:52:55 2014 +0200 radeon: enable Hyper-Z on r600g and radeonsi by default This reverts commit 01e637114914453451becc0dc8afe60faff48d84. Since then many Hyper-Z issues have been fixed or worked around. Enable Hyper-Z by default so that we get enough feedback for the upcoming mesa 10.4 release. If you have issues with Hyper-Z try to disable Hyper-Z using the enviroment variable R600_DEBUG=nohyperz and please report the issue on the bugtracker. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75011 See also: https://bugs.freedesktop.org/show_bug.cgi?id=75112 Signed-off-by: Andreas Boll Reviewed-by: Marek Ol??k -- 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/20141024/c2e97aef/attachment.html>
[RFC 1/2] PM / Domains: Power on domain early during system resume
On czw, 2014-10-23 at 19:20 +0300, Grygorii Strashko wrote: > Hi Krzysztof, > > On 10/23/2014 04:48 PM, Krzysztof Kozlowski wrote: > > When resuming the system the power domain has to be powered on early so > > any runtime PM aware devices could resume. > > > > This fixes following scenario reproduced on Exynos DRM: > > 1. Power domain is off before suspending the system. > > 2. System is suspended to RAM. > > 3. Resuming starts. The Exynos DRM driver resume callback is called. > > 4. The Exynos DRM driver calls drm_helper_resume_force_mode which turns > > the screen on by calling exynos_dsi_dpms with DRM_MODE_DPMS_ON. > > 5. The Exynos DSI driver calls pm_runtime_get. The driver runtime > > resumes and this should turn LCD power domain on. > > 6. Unfortunately the domain cannot be turned on because system resume is > > in progress and genpd->prepared_count is positive. > > Just interesting, what value will be returned by pm_runtime_enabled() > from any of your .resume() callback (for any device which belongs to > some Generic PM domain)? exynos_drm_resume: false exynos_dsi_enable: true Full backtrace leading to exynos_dsi_enable: [ 37.944830] [ cut here ] [ 37.944860] WARNING: CPU: 0 PID: 3125 at drivers/gpu/drm/exynos/exynos_drm_dsi.c:1360 exynos_dsi_dpms+0xc0/0x398() [ 37.944869] Modules linked in: [ 37.944883] CPU: 0 PID: 3125 Comm: bash Tainted: GW 3.17.0-next-20141020-00050-g844ed80678d5-dirty #479 [ 37.944923] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [ 37.944949] [] (show_stack) from [] (dump_stack+0x70/0xbc) [ 37.944977] [] (dump_stack) from [] (warn_slowpath_common+0x64/0x88) [ 37.944992] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) [ 37.945011] [] (warn_slowpath_null) from [] (exynos_dsi_dpms+0xc0/0x398) [ 37.945024] [] (exynos_dsi_dpms) from [] (exynos_drm_encoder_commit+0x24/0x40) [ 37.945044] [] (exynos_drm_encoder_commit) from [] (drm_crtc_helper_set_mode+0x400/0x4e8) [ 37.945057] [] (drm_crtc_helper_set_mode) from [] (drm_helper_resume_force_mode+0x68/0x124) [ 37.945083] [] (drm_helper_resume_force_mode) from [] (exynos_drm_resume+0x80/0x90) [ 37.945100] [] (exynos_drm_resume) from [] (platform_pm_resume+0x2c/0x4c) [ 37.945118] [] (platform_pm_resume) from [] (dpm_run_callback.isra.7+0x2c/0x64) [ 37.945130] [] (dpm_run_callback.isra.7) from [] (device_resume+0xac/0x180) [ 37.945141] [] (device_resume) from [] (dpm_resume+0xe8/0x20c) [ 37.945152] [] (dpm_resume) from [] (dpm_resume_end+0xc/0x18) [ 37.945175] [] (dpm_resume_end) from [] (suspend_devices_and_enter+0x230/0x3c8) [ 37.945190] [] (suspend_devices_and_enter) from [] (pm_suspend+0x268/0x29c) [ 37.945202] [] (pm_suspend) from [] (state_store+0x6c/0xbc) [ 37.945220] [] (state_store) from [] (kobj_attr_store+0x14/0x20) [ 37.945235] [] (kobj_attr_store) from [] (sysfs_kf_write+0x44/0x48) [ 37.945245] [] (sysfs_kf_write) from [] (kernfs_fop_write+0xc0/0x17c) [ 37.945268] [] (kernfs_fop_write) from [] (vfs_write+0xa0/0x1a8) [ 37.945282] [] (vfs_write) from [] (SyS_write+0x40/0x8c) [ 37.945299] [] (SyS_write) from [] (ret_fast_syscall+0x0/0x30) [ 37.945307] ---[ end trace e930e0edfd9a5ad2 ]--- > I'm asking, because as I can see Runtime PM can be disabled from > pm_genpd_prepare(). > > Thank you. > > Oh. I've just found that you might get this issue if you will try to do > suspend when PM domain is ON ;) > > Any way, In my opinion, It might be better to fix pm_genpd_prepare() so > it will not increment prepared_count when initial state of the GPD is > GPD_STATE_POWER_OFF. Seems it's needed only in opposite case - > when state of GPD has to be restored from pm_genpd_resume_noirq(). That sounds good but what about cases when the device will runtime resume during suspend (early at suspend)? Actually I seen this with framebuffer console. Right after starting suspend the console is flushed and poked which leads to powering on LCD. Best regards, Krzysztof
[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75112 --- Comment #20 from Andreas Boll --- Hyper-Z has been re-enabled by default with commit 14bdcc6ff98664552216acfdb7e35d0b128003ef Author: Andreas Boll Date: Thu Oct 23 14:52:55 2014 +0200 radeon: enable Hyper-Z on r600g and radeonsi by default This reverts commit 01e637114914453451becc0dc8afe60faff48d84. Since then many Hyper-Z issues have been fixed or worked around. Enable Hyper-Z by default so that we get enough feedback for the upcoming mesa 10.4 release. If you have issues with Hyper-Z try to disable Hyper-Z using the enviroment variable R600_DEBUG=nohyperz and please report the issue on the bugtracker. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75011 See also: https://bugs.freedesktop.org/show_bug.cgi?id=75112 Signed-off-by: Andreas Boll Reviewed-by: Marek Ol??k Please help testing. -- 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/20141024/7287945a/attachment.html>
tile property contents
On Fri, Oct 24, 2014 at 05:25:58PM +1000, Dave Airlie wrote: > >> > > There are also configurations where users configure multiple heads to > >> > > drive power walls that they want to be treated as one logical monitor, > >> > > similar to the DP MST tiled display case. Normally, those powerwall > >> > > configurations don't have any layout information from the monitors > >> > > themselves, and the layout is configured by the user. > >> > > > >> > > Would it be appropriate for users to be able to set the TILE property > >> > > in that sort of scenario? > >> > > > >> > > For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc > >> > > should be expressed in pixels rather than tiles? Sometimes, the tiles > >> > > in those powerwalls may not all have the same resolution, or may be > >> > > configured with overlap. I suppose that would make the TILE > >> > > configuration > >> > > specific to the current modetimings on each tile... > >> > > >> > Why can't users just set that mode? > >> > >> Sure, users can set the mode, but: > >> > >> * Part of what the TILE property conveys is how monitors should be grouped > >> for purposes of window maximization. Users don't have a great way to > >> express that today, that I'm aware of. > > > > My understanding for why we want the TILE property is to avoid to > > duplicate displayId parsing over every bit of userspace (and the fbcon > > stuff in the kernel) interested in it. Imo the proper way for userspace is > > to always just inherit whatever modeset config is already there. > > Andy's idea is good, I'd considered it before, the problem being how > to expose it nicely, > > not sure if you'd want persistent via /sys or dynamic setting of the > property by user for that session, so we could do it like xrandr > modes. > > Daniel you are missing the nice case of using TILE for non-displayid > monitors once the infrastructure is in place. > > Having it so you can create user defined tile groups to allow users to > configure arbitrary walls is a useful thing, that you can't do any > other way. > > > > >> * Users might configure the mode they want, but then gnome-settings-daemon > >> may come along later and decide it knows better than the user how things > >> should be configured. One scenario where this comes up is: > >> (a) user meticulously configures his power wall > >> (b) user hotplugs another monitor > >> I've definitely seen cases where window managers will try to be clever > >> in response to a hotplug, and clobber the user's current configuration. > >> If the TILE property conveyed how some set of monitors was supposed > >> to be grouped, that would hopefully give window managers additional > >> information, such that they would know to keep that group intact. > > > > Well, imnsho gnome display control center is a bit too opiniated about > > automatic modeset changes. If their assumption is that they always know > > perfectly what the user wants upon hotplug I really don't want to work > > around this in the kernel. Since for everything else than a laptop + > > beamer gnome panel always pisses me off ;-) > > > > I think gnome should just ask the user what it wants if there's more than > > 2 physical displays (treating a tiled 4k screen as one ofc), since there's > > really no way at all to tell. > > Well its not just a GNOME problem either, once things like SDL respect > tIle properrty, > we can create arbitary tile walls that the whole stack will respect, > instead of hacks > like fake xinerama. Hm yeah if we want tile walls als logical displays for full-screening and all that then this makes indeed sense. I didn't really consider that part, was probably thrown off by Andy's comments that some tile walls aren't pixel aligned which would look funky for full-screen apps I guess. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH v2 1/9] drm: rcar-du: Remove platform data support
All platforms now instantiate the DU through DT, platform data support
isn't needed anymore.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h| 10 -
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 4 +-
drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 -
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 8 +---
drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 10 +++--
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 52 +++---
drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 26 +--
drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h | 2 -
drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h | 1 -
include/linux/platform_data/rcar-du.h | 74 ---
10 files changed, 38 insertions(+), 151 deletions(-)
delete mode 100644 include/linux/platform_data/rcar-du.h
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index e97ae502dec5..984e6083699f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -15,7 +15,6 @@
#define __RCAR_DU_CRTC_H__
#include
-#include
#include
#include
@@ -41,6 +40,15 @@ struct rcar_du_crtc {
#define to_rcar_crtc(c)container_of(c, struct rcar_du_crtc, crtc)
+enum rcar_du_output {
+ RCAR_DU_OUTPUT_DPAD0,
+ RCAR_DU_OUTPUT_DPAD1,
+ RCAR_DU_OUTPUT_LVDS0,
+ RCAR_DU_OUTPUT_LVDS1,
+ RCAR_DU_OUTPUT_TCON,
+ RCAR_DU_OUTPUT_MAX,
+};
+
int rcar_du_crtc_create(struct rcar_du_group *rgrp, unsigned int index);
void rcar_du_crtc_enable_vblank(struct rcar_du_crtc *rcrtc, bool enable);
void rcar_du_crtc_cancel_page_flip(struct rcar_du_crtc *rcrtc,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
index d212efa6a495..967ae8f20233 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
@@ -146,12 +146,11 @@ static int rcar_du_load(struct drm_device *dev, unsigned
long flags)
{
struct platform_device *pdev = dev->platformdev;
struct device_node *np = pdev->dev.of_node;
- struct rcar_du_platform_data *pdata = pdev->dev.platform_data;
struct rcar_du_device *rcdu;
struct resource *mem;
int ret;
- if (pdata == NULL && np == NULL) {
+ if (np == NULL) {
dev_err(dev->dev, "no platform data\n");
return -ENODEV;
}
@@ -163,7 +162,6 @@ static int rcar_du_load(struct drm_device *dev, unsigned
long flags)
}
rcdu->dev = &pdev->dev;
- rcdu->pdata = pdata;
rcdu->info = np ? of_match_device(rcar_du_of_table, rcdu->dev)->data
: (void *)platform_get_device_id(pdev)->driver_data;
rcdu->ddev = dev;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
index 8e494633c3b3..0a724669f02d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_drv.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.h
@@ -15,7 +15,6 @@
#define __RCAR_DU_DRV_H__
#include
-#include
#include "rcar_du_crtc.h"
#include "rcar_du_group.h"
@@ -67,7 +66,6 @@ struct rcar_du_device_info {
struct rcar_du_device {
struct device *dev;
- const struct rcar_du_platform_data *pdata;
const struct rcar_du_device_info *info;
void __iomem *mmio;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 7c0ec95915ef..89ed4a929f7b 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -142,7 +142,6 @@ static const struct drm_encoder_funcs encoder_funcs = {
int rcar_du_encoder_init(struct rcar_du_device *rcdu,
enum rcar_du_encoder_type type,
enum rcar_du_output output,
-const struct rcar_du_encoder_data *data,
struct device_node *np)
{
struct rcar_du_encoder *renc;
@@ -190,11 +189,8 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
drm_encoder_helper_add(&renc->encoder, &encoder_helper_funcs);
switch (encoder_type) {
- case DRM_MODE_ENCODER_LVDS: {
- const struct rcar_du_panel_data *pdata =
- data ? &data->connector.lvds.panel : NULL;
- return rcar_du_lvds_connector_init(rcdu, renc, pdata, np);
- }
+ case DRM_MODE_ENCODER_LVDS:
+ return rcar_du_lvds_connector_init(rcdu, renc, np);
case DRM_MODE_ENCODER_DAC:
return rcar_du_vga_connector_init(rcdu, renc);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index bd624135ef1f..c37ed9499542 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
@@ -14,13 +14,18 @@
#ifndef __RCAR_DU_ENCODER_H__
#define __RCAR_DU_ENCODER_H__
-#include
-
#include
struct rcar_du_device;
struct rcar_du_lvdsenc;
+enum rcar_du_e
[PATCH v2 3/9] drm: rcar-du: Replace direct DRM encoder access with cast macro
Add a new macro to downcast an rcar_du_encoder pointer to a drm_encoder
pointer and use it. This prepares for the replacement of the
rcar_drm_encoder encoder field with a drm_slave_encoder.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 8 +---
drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 2 ++
drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 5 +++--
drivers/gpu/drm/rcar-du/rcar_du_vgacon.c | 5 +++--
4 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index c699100a1359..e88e63b06b09 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -33,7 +33,7 @@ rcar_du_connector_best_encoder(struct drm_connector
*connector)
{
struct rcar_du_connector *rcon = to_rcar_connector(connector);
- return &rcon->encoder->encoder;
+ return rcar_encoder_to_drm_encoder(rcon->encoder);
}
/*
-
@@ -146,6 +146,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
struct device_node *con_node)
{
struct rcar_du_encoder *renc;
+ struct drm_encoder *encoder;
unsigned int encoder_type;
int ret;
@@ -154,6 +155,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
return -ENOMEM;
renc->output = output;
+ encoder = rcar_encoder_to_drm_encoder(renc);
switch (output) {
case RCAR_DU_OUTPUT_LVDS0:
@@ -182,12 +184,12 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
break;
}
- ret = drm_encoder_init(rcdu->ddev, &renc->encoder, &encoder_funcs,
+ ret = drm_encoder_init(rcdu->ddev, encoder, &encoder_funcs,
encoder_type);
if (ret < 0)
return ret;
- drm_encoder_helper_add(&renc->encoder, &encoder_helper_funcs);
+ drm_encoder_helper_add(encoder, &encoder_helper_funcs);
switch (encoder_type) {
case DRM_MODE_ENCODER_LVDS:
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index 4b906b90c204..c6334b4280d9 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
@@ -35,6 +35,8 @@ struct rcar_du_encoder {
#define to_rcar_encoder(e) \
container_of(e, struct rcar_du_encoder, encoder)
+#define rcar_encoder_to_drm_encoder(e) (&(e)->encoder)
+
struct rcar_du_connector {
struct drm_connector connector;
struct rcar_du_encoder *encoder;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
index 80dc02166c88..6d9811c052c4 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c
@@ -84,6 +84,7 @@ int rcar_du_lvds_connector_init(struct rcar_du_device *rcdu,
struct rcar_du_encoder *renc,
/* TODO const */ struct device_node *np)
{
+ struct drm_encoder *encoder = rcar_encoder_to_drm_encoder(renc);
struct rcar_du_lvds_connector *lvdscon;
struct drm_connector *connector;
struct display_timing timing;
@@ -120,11 +121,11 @@ int rcar_du_lvds_connector_init(struct rcar_du_device
*rcdu,
drm_object_property_set_value(&connector->base,
rcdu->ddev->mode_config.dpms_property, DRM_MODE_DPMS_OFF);
- ret = drm_mode_connector_attach_encoder(connector, &renc->encoder);
+ ret = drm_mode_connector_attach_encoder(connector, encoder);
if (ret < 0)
return ret;
- connector->encoder = &renc->encoder;
+ connector->encoder = encoder;
lvdscon->connector.encoder = renc;
return 0;
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
index 564a723ede03..752747a5e920 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vgacon.c
@@ -52,6 +52,7 @@ static const struct drm_connector_funcs connector_funcs = {
int rcar_du_vga_connector_init(struct rcar_du_device *rcdu,
struct rcar_du_encoder *renc)
{
+ struct drm_encoder *encoder = rcar_encoder_to_drm_encoder(renc);
struct rcar_du_connector *rcon;
struct drm_connector *connector;
int ret;
@@ -78,11 +79,11 @@ int rcar_du_vga_connector_init(struct rcar_du_device *rcdu,
drm_object_property_set_value(&connector->base,
rcdu->ddev->mode_config.dpms_property, DRM_MODE_DPMS_OFF);
- ret = drm_mode_connector_attach_encoder(connector, &renc->encoder);
+ ret = drm_mode_connector_attach_encoder(connector, encoder);
if (ret < 0)
return ret;
- connector->encoder = &renc->encoder;
+ connector->encoder = encoder;
rcon->encoder
[PATCH v2 0/9] Renesas R-Car DU HDMI support
Hello, This patch set adds support for the HDMI output port present on the Renesas Koelsch board. Doing so requires two components, a driver for the external ADV7511W HDMI encoder, and support for HDMI encoders in the DU driver. The HDMI encoder drivers uses the DRM slave encoder framework and the component framework to communicate with the DU driver. The DT bindings are based on the OF graph bindings to link the display controller and encoder. The first two patches have been taken from Philipp Zabel's "[PATCH v3 0/8] Add of-graph helpers to loop over endpoints and find ports by id" series. Philipp, I don't see that series in linux-next, what's the merge status ? The R-Car DU patches start with a bit of refactoring, to finally add HDMI support in patch 08/12. The new adv7511 driver (patch 11/12) depends on decoupling EDID parsing from the DDC I2C adapter (patch 09/12). It supports DT instantiation only (bindings are documented in patch 10/12) for now. Platform data support could be added later if needed. The code is based on Lars-Peter Clausen's adv7511 driver, with heavy modifications. The last patch instantiates the HDMI encoder in the Koelsch board DT file and connects it to the DU output. The patch series depends on Koelsch DU DT enablement (scheduled for merge in v3.19-rc1). Dave, I'd like to get this merged in v3.19-rc1, how would you like to proceed ? Could it go through Simon's Renesas tree ? There's a small risk of conflict in drivers/gpu/drm/drm_edid.c, include/drm/drm_edid.h, drivers/gpu/drm/i2c/Kconfig and drivers/gpu/drm/i2c/Makefile. Simon, could you alternatively provide a stable branch with the required dependencies ? Changes since v1: - Dropped Philipp Zabel's OF graph patches (the rcar-du-drm driver will be udpated to use for_each_endpoint_of_node when the implementation hits upstream) - adv7511: Clarify the adi,input-format DT property documentation - adv7511: Use map array to convert input style to hardware value - adv7511: Fixed typos For ease of testing and review I've pushed this series and its dependencies to a git branch on git://linuxtv.org/pinchartl/fbdev.git drm/du/adv7511 Cc: devicetree at vger.kernel.org Lars-Peter Clausen (2): drm: Decouple EDID parsing from I2C adapter drm: Add adv7511 encoder driver Laurent Pinchart (7): drm: rcar-du: Remove platform data support drm: rcar-du: Pass the encoder DT node to rcar_du_encoder_init() drm: rcar-du: Replace direct DRM encoder access with cast macro drm: rcar-du: Replace drm_encoder with drm_slave_encoder drm: rcar-du: Add HDMI encoder and connector support video: Add ADV751[13] DT bindings documentation ARM: shmobile: koelsch: Add DU HDMI output support .../devicetree/bindings/video/adi,adv7511.txt | 88 ++ arch/arm/boot/dts/r8a7791-koelsch.dts | 50 +- drivers/gpu/drm/drm_edid.c | 26 +- drivers/gpu/drm/i2c/Kconfig|6 + drivers/gpu/drm/i2c/Makefile |2 + drivers/gpu/drm/i2c/adv7511.c | 1010 drivers/gpu/drm/i2c/adv7511.h | 289 ++ drivers/gpu/drm/rcar-du/Kconfig| 11 +- drivers/gpu/drm/rcar-du/Makefile |2 + drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 10 +- drivers/gpu/drm/rcar-du/rcar_du_drv.c |4 +- drivers/gpu/drm/rcar-du/rcar_du_drv.h |2 - drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 45 +- drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 23 +- drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c | 118 +++ drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h | 31 + drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 151 +++ drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h | 35 + drivers/gpu/drm/rcar-du/rcar_du_kms.c | 53 +- drivers/gpu/drm/rcar-du/rcar_du_lvdscon.c | 31 +- drivers/gpu/drm/rcar-du/rcar_du_lvdscon.h |2 - drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.h |1 - drivers/gpu/drm/rcar-du/rcar_du_vgacon.c |5 +- include/drm/drm_edid.h |4 + include/linux/platform_data/rcar-du.h | 74 -- 25 files changed, 1892 insertions(+), 181 deletions(-) create mode 100644 Documentation/devicetree/bindings/video/adi,adv7511.txt create mode 100644 drivers/gpu/drm/i2c/adv7511.c create mode 100644 drivers/gpu/drm/i2c/adv7511.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h delete mode 100644 include/linux/platform_data/rcar-du.h -- Regards, Laurent Pinchart
[PATCH v2 2/9] drm: rcar-du: Pass the encoder DT node to rcar_du_encoder_init()
The encoder DT node will be needed to register an external HDMI encoder.
Pass it to the rcar_du_encoder_init() function to prepare for HDMI
support.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 5 +++--
drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 3 ++-
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 2 +-
3 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index 89ed4a929f7b..c699100a1359 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -142,7 +142,8 @@ static const struct drm_encoder_funcs encoder_funcs = {
int rcar_du_encoder_init(struct rcar_du_device *rcdu,
enum rcar_du_encoder_type type,
enum rcar_du_output output,
-struct device_node *np)
+struct device_node *enc_node,
+struct device_node *con_node)
{
struct rcar_du_encoder *renc;
unsigned int encoder_type;
@@ -190,7 +191,7 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
switch (encoder_type) {
case DRM_MODE_ENCODER_LVDS:
- return rcar_du_lvds_connector_init(rcdu, renc, np);
+ return rcar_du_lvds_connector_init(rcdu, renc, con_node);
case DRM_MODE_ENCODER_DAC:
return rcar_du_vga_connector_init(rcdu, renc);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index c37ed9499542..4b906b90c204 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
@@ -49,6 +49,7 @@ rcar_du_connector_best_encoder(struct drm_connector
*connector);
int rcar_du_encoder_init(struct rcar_du_device *rcdu,
enum rcar_du_encoder_type type,
enum rcar_du_output output,
-struct device_node *np);
+struct device_node *enc_node,
+struct device_node *con_node);
#endif /* __RCAR_DU_ENCODER_H__ */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index c6a7fd604d46..bd3b7c48ce1f 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -289,7 +289,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device
*rcdu,
connector = entity;
}
- ret = rcar_du_encoder_init(rcdu, enc_type, output, connector);
+ ret = rcar_du_encoder_init(rcdu, enc_type, output, encoder, connector);
of_node_put(encoder);
of_node_put(connector);
--
2.0.4
[PATCH v2 4/9] drm: rcar-du: Replace drm_encoder with drm_slave_encoder
DRM slave encoders require their associated struct drm_encoder instance
to be embedded in a struct drm_slave_encoder. This makes processing
encoders regardless of their types needlessly and painfully complex in
drivers that use a mix of slave encoders and custom encoders. Such a
driver will need to either create drm_slave_encoder instances that fake
their embedded encoder instance, or to turn all drm_encoder instances
into drm_slave_encoder instances.
Between the two evils, one must choose the lesser. Use drm_slave_encoder
everywhere.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index c6334b4280d9..c4dccdbcff33 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
@@ -15,6 +15,7 @@
#define __RCAR_DU_ENCODER_H__
#include
+#include
struct rcar_du_device;
struct rcar_du_lvdsenc;
@@ -27,15 +28,15 @@ enum rcar_du_encoder_type {
};
struct rcar_du_encoder {
- struct drm_encoder encoder;
+ struct drm_encoder_slave slave;
enum rcar_du_output output;
struct rcar_du_lvdsenc *lvds;
};
#define to_rcar_encoder(e) \
- container_of(e, struct rcar_du_encoder, encoder)
+ container_of(e, struct rcar_du_encoder, slave.base)
-#define rcar_encoder_to_drm_encoder(e) (&(e)->encoder)
+#define rcar_encoder_to_drm_encoder(e) (&(e)->slave.base)
struct rcar_du_connector {
struct drm_connector connector;
--
2.0.4
[PATCH v2 9/9] ARM: shmobile: koelsch: Add DU HDMI output support
Add DT nodes for the ADV7511 HDMI encoder and its HDMI output connector
and configure the DISP pin group that drives the HDMI transmitter DE
pin.
Signed-off-by: Laurent Pinchart
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 50 ++-
1 file changed, 49 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 0402c498b05b..317f5788a00c 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -210,6 +210,17 @@
states = <330 1
180 0>;
};
+
+ hdmi-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con: endpoint {
+ remote-endpoint = <&adv7511_out>;
+ };
+ };
+ };
};
&du {
@@ -218,6 +229,11 @@
status = "okay";
ports {
+ port at 0 {
+ endpoint {
+ remote-endpoint = <&adv7511_in>;
+ };
+ };
port at 1 {
lvds_connector: endpoint {
};
@@ -236,7 +252,7 @@
};
du_pins: du {
- renesas,groups = "du_rgb666", "du_sync", "du_clk_out_0";
+ renesas,groups = "du_rgb666", "du_sync", "du_disp",
"du_clk_out_0";
renesas,function = "du";
};
@@ -440,6 +456,38 @@
};
};
+ hdmi at 39 {
+ compatible = "adi,adv7511w";
+ reg = <0x39>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ adv7511_in: endpoint {
+ remote-endpoint = <&du_out_rgb>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_con>;
+ };
+ };
+ };
+ };
+
eeprom at 50 {
compatible = "renesas,24c02";
reg = <0x50>;
--
2.0.4
[PATCH v2 8/9] drm: Add adv7511 encoder driver
From: Lars-Peter Clausen
This patch adds a driver for the Analog Devices adv7511. The adv7511 is
a standalone HDMI transmitter chip. It features a HDMI output interface
on one end and video and audio input interfaces on the other.
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Laurent Pinchart
---
This commit incorporates the following commits.
DRM: adv7511: Sync to latest version
DRM: adv7511: Fix calculation and setting of CTS
DRM: adv7511: Write status word frequency and word len registers
adv7511: Remove some debug printks
Merge branch 'xcomm_zynq' into xcomm_zynq_3_5
Sync adv7511 and axi-hdmi driver to latest version
drm:adv7511: Re-add module information
DRM: adv7511: Don't use raw_edid to pass edid data
drm: adv7511: Ignore the csc scaling factor when the csc is disabled
drm: adv7511: Check if edid is NULL before duplicating it
drm: adv7511: Include the extension sections when duplicating the edid
DRM: adv7511: Work around off-by-one hardware bug
DRM: adv7511: Make embedded sync generator setup more robust
DRM: adv7511_audio: Fix typo
DRM: adv7511: Add powerdown gpio support
drm: adv7511: Fix use after free
DRM: adv7511: Properly initialize dpms_mode and status
DRM: adv7511: Avoid uneccessary disconnected events
drm: adv7511: Fix adv7511 encoder driver
drm: adv7511: Fix kernel-doc format
drm: adv7511: Fix adv7511_parse_dt()
drm: adv7511: Add the rgb format flag to adv7511_link_config
drm: adv7511: Configure CSC in adv7511_set_config()
drm: adv7511: Add adv7511_set_config_csc()
drm: adv7511: Configure the csc when getting modes
drm: adv7511: Add adv7511_encoder_mode_valid() function
drm: adv7511: Don't export adv7511_get_edid function
drm: adv7511: Mark the revision register as volatile
drm: adv7511: Initialize work queue before requesting IRQ
drm: adv7511: Remove trailing whitespaces
drm: adv7511: Remove audio support
drm: adv7511: Remove DRM slave encoder .set_config operation
drm: adv7511: Make the adv7511_packet_(enable|disable) functions static
drm: adv7511: Move Kconfig entry to drivers/gpu/drm/i2c/Kconfig
drm: adv7511: Update to the latest DRM API
drm: adv7511: Rename driver source file to adv7511.c
drm: adv7511: Add OF match table
drm: adv7511: Add ADV7513 support
drm: adv7511: Remove platform data support
drm: adv7511: Convert to the gpiod API
drm: adv7511: Remove packet and CEC I2C device support
drm: adv7511: Use the devm_ managed IRQ API
drm: adv7511: Remove unneeded local variable initialization
drm: adv7511: Pass the adv7511 pointer to adv7511_get_edid_block
drm: adv7511: Make loop counter unsigned
drm: adv7511: Pass adv7511 pointer to adv7511_set_config_csc function
drm: adv7511: Reorganize the code in sections
drm: adv7511: Simplify DT bindings
drm: adv7511: Use map array to convert input style to hardware value
---
drivers/gpu/drm/i2c/Kconfig |6 +
drivers/gpu/drm/i2c/Makefile |2 +
drivers/gpu/drm/i2c/adv7511.c | 1010 +
drivers/gpu/drm/i2c/adv7511.h | 289
4 files changed, 1307 insertions(+)
create mode 100644 drivers/gpu/drm/i2c/adv7511.c
create mode 100644 drivers/gpu/drm/i2c/adv7511.h
diff --git a/drivers/gpu/drm/i2c/Kconfig b/drivers/gpu/drm/i2c/Kconfig
index 4d341db462a2..22c7ed63a001 100644
--- a/drivers/gpu/drm/i2c/Kconfig
+++ b/drivers/gpu/drm/i2c/Kconfig
@@ -1,6 +1,12 @@
menu "I2C encoder or helper chips"
depends on DRM && DRM_KMS_HELPER && I2C
+config DRM_I2C_ADV7511
+ tristate "AV7511 encoder"
+ select REGMAP_I2C
+ help
+ Support for the Analog Device ADV7511(W) and ADV7513 HDMI encoders.
+
config DRM_I2C_CH7006
tristate "Chrontel ch7006 TV encoder"
default m if DRM_NOUVEAU
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 43aa33baebed..2c72eb584ab7 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -1,5 +1,7 @@
ccflags-y := -Iinclude/drm
+obj-$(CONFIG_DRM_I2C_ADV7511) += adv7511.o
+
ch7006-y := ch7006_drv.o ch7006_mode.o
obj-$(CONFIG_DRM_I2C_CH7006) += ch7006.o
diff --git a/drivers/gpu/drm/i2c/adv7511.c b/drivers/gpu/drm/i2c/adv7511.c
new file mode 100644
index ..faf1c0c5ab2e
--- /dev/null
+++ b/drivers/gpu/drm/i2c/adv7511.c
@@ -0,0 +1,1010 @@
+/*
+ * Analog Devices ADV7511 HDMI transmitter driver
+ *
+ * Copyright 2012 Analog Devices Inc.
+ *
+ * Licensed under the GPL-2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+#include "adv7511.h"
+
+struct adv7511 {
+ struct i2c_client *i2c_main;
+ struct i2c_client *i2c_edid;
+
+ struct regmap *regmap;
+ struct regmap *packet_memory_regmap;
+ enum drm_connector_status status;
+ int dpms_mode;
+
+ unsigned int f_tmds;
+
+ unsigned int current_edid_segment;
+ uint8_t edid_buf[256];
+
+ wait_queue_head_t wq;
+ struct drm_encoder *encoder;
+
+ bool embedded_sync;
+ enum adv7511_
[PATCH v2 5/9] drm: rcar-du: Add HDMI encoder and connector support
SoCs that integrate the DU have no internal HDMI encoder, support
external encoders only.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/Kconfig | 11 ++-
drivers/gpu/drm/rcar-du/Makefile | 2 +
drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 30 +-
drivers/gpu/drm/rcar-du/rcar_du_encoder.h | 3 +
drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c | 118 +++
drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h | 31 ++
drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c | 151 ++
drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h | 35 +++
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 1 +
9 files changed, 375 insertions(+), 7 deletions(-)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmicon.h
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_hdmienc.h
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index c96f6089f8bf..2324a526de65 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -11,10 +11,17 @@ config DRM_RCAR_DU
Choose this option if you have an R-Car chipset.
If M is selected the module will be called rcar-du-drm.
+config DRM_RCAR_HDMI
+ bool "R-Car DU HDMI Encoder Support"
+ depends on DRM_RCAR_DU
+ depends on OF
+ help
+ Enable support for external HDMI encoders.
+
config DRM_RCAR_LVDS
bool "R-Car DU LVDS Encoder Support"
depends on DRM_RCAR_DU
depends on ARCH_R8A7790 || ARCH_R8A7791 || COMPILE_TEST
help
- Enable support the R-Car Display Unit embedded LVDS encoders
- (currently only on R8A7790).
+ Enable support for the R-Car Display Unit embedded LVDS encoders
+ (currently only on R8A7790 and R8A7791).
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 12b8d4477835..05de1c4097af 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -7,6 +7,8 @@ rcar-du-drm-y := rcar_du_crtc.o \
rcar_du_plane.o \
rcar_du_vgacon.o
+rcar-du-drm-$(CONFIG_DRM_RCAR_HDMI)+= rcar_du_hdmicon.o \
+ rcar_du_hdmienc.o
rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_lvdsenc.o
obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
index e88e63b06b09..34a122a39664 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_encoder.c
@@ -19,6 +19,8 @@
#include "rcar_du_drv.h"
#include "rcar_du_encoder.h"
+#include "rcar_du_hdmicon.h"
+#include "rcar_du_hdmienc.h"
#include "rcar_du_kms.h"
#include "rcar_du_lvdscon.h"
#include "rcar_du_lvdsenc.h"
@@ -177,6 +179,9 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
case RCAR_DU_ENCODER_LVDS:
encoder_type = DRM_MODE_ENCODER_LVDS;
break;
+ case RCAR_DU_ENCODER_HDMI:
+ encoder_type = DRM_MODE_ENCODER_TMDS;
+ break;
case RCAR_DU_ENCODER_NONE:
default:
/* No external encoder, use the internal encoder type. */
@@ -184,12 +189,24 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
break;
}
- ret = drm_encoder_init(rcdu->ddev, encoder, &encoder_funcs,
- encoder_type);
- if (ret < 0)
- return ret;
+ if (type == RCAR_DU_ENCODER_HDMI) {
+ if (renc->lvds) {
+ dev_err(rcdu->dev,
+ "Chaining LVDS and HDMI encoders not
supported\n");
+ return -EINVAL;
+ }
- drm_encoder_helper_add(encoder, &encoder_helper_funcs);
+ ret = rcar_du_hdmienc_init(rcdu, renc, enc_node);
+ if (ret < 0)
+ return ret;
+ } else {
+ ret = drm_encoder_init(rcdu->ddev, encoder, &encoder_funcs,
+ encoder_type);
+ if (ret < 0)
+ return ret;
+
+ drm_encoder_helper_add(encoder, &encoder_helper_funcs);
+ }
switch (encoder_type) {
case DRM_MODE_ENCODER_LVDS:
@@ -198,6 +215,9 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
case DRM_MODE_ENCODER_DAC:
return rcar_du_vga_connector_init(rcdu, renc);
+ case DRM_MODE_ENCODER_TMDS:
+ return rcar_du_hdmi_connector_init(rcdu, renc);
+
default:
return -EINVAL;
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
b/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
index c4dccdbcff33..719b6f2a031c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_encoder.h
+++ b/drivers/gpu/dr
[PATCH v2 6/9] drm: Decouple EDID parsing from I2C adapter
From: Lars-Peter Clausen
The drm_get_edid() function performs direct I2C accesses to read EDID
blocks, assuming that the monitor DDC interface is directly connected to
the I2C bus. It can't thus be used with HDMI encoders that control the
DDC bus and expose EDID blocks through a different interface.
Refactor drm_do_get_edid() to take a block read callback function
instead of an I2C adapter, and export it for direct use by drivers.
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/drm_edid.c | 26 +-
include/drm/drm_edid.h | 4
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 3bf999134bcc..906809380c66 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1125,9 +1125,9 @@ EXPORT_SYMBOL(drm_edid_is_valid);
* Return: 0 on success or -1 on failure.
*/
static int
-drm_do_probe_ddc_edid(struct i2c_adapter *adapter, unsigned char *buf,
- int block, int len)
+drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned int block, size_t len)
{
+ struct i2c_adapter *adapter = data;
unsigned char start = block * EDID_LENGTH;
unsigned char segment = block >> 1;
unsigned char xfers = segment ? 3 : 2;
@@ -1184,8 +1184,9 @@ static bool drm_edid_is_zero(u8 *in_edid, int length)
return true;
}
-static u8 *
-drm_do_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter)
+struct edid *drm_do_get_edid(struct drm_connector *connector,
+ int (*get_edid_block)(void *, u8 *buf, unsigned int, size_t),
+ void *data)
{
int i, j = 0, valid_extensions = 0;
u8 *block, *new;
@@ -1196,7 +1197,7 @@ drm_do_get_edid(struct drm_connector *connector, struct
i2c_adapter *adapter)
/* base block fetch */
for (i = 0; i < 4; i++) {
- if (drm_do_probe_ddc_edid(adapter, block, 0, EDID_LENGTH))
+ if (get_edid_block(data, block, 0, EDID_LENGTH))
goto out;
if (drm_edid_block_valid(block, 0, print_bad_edid))
break;
@@ -1210,7 +1211,7 @@ drm_do_get_edid(struct drm_connector *connector, struct
i2c_adapter *adapter)
/* if there's no extensions, we're done */
if (block[0x7e] == 0)
- return block;
+ return (struct edid *)block;
new = krealloc(block, (block[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
if (!new)
@@ -1219,7 +1220,7 @@ drm_do_get_edid(struct drm_connector *connector, struct
i2c_adapter *adapter)
for (j = 1; j <= block[0x7e]; j++) {
for (i = 0; i < 4; i++) {
- if (drm_do_probe_ddc_edid(adapter,
+ if (get_edid_block(data,
block + (valid_extensions + 1) * EDID_LENGTH,
j, EDID_LENGTH))
goto out;
@@ -1247,7 +1248,7 @@ drm_do_get_edid(struct drm_connector *connector, struct
i2c_adapter *adapter)
block = new;
}
- return block;
+ return (struct edid *)block;
carp:
if (print_bad_edid) {
@@ -1260,6 +1261,7 @@ out:
kfree(block);
return NULL;
}
+EXPORT_SYMBOL_GPL(drm_do_get_edid);
/**
* drm_probe_ddc() - probe DDC presence
@@ -1289,12 +1291,10 @@ EXPORT_SYMBOL(drm_probe_ddc);
struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
- struct edid *edid = NULL;
-
- if (drm_probe_ddc(adapter))
- edid = (struct edid *)drm_do_get_edid(connector, adapter);
+ if (!drm_probe_ddc(adapter))
+ return NULL;
- return edid;
+ return drm_do_get_edid(connector, drm_do_probe_ddc_edid, adapter);
}
EXPORT_SYMBOL(drm_get_edid);
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index b96031d947a0..bcf05ef0caf8 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -279,4 +279,8 @@ int
drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe
*frame,
const struct drm_display_mode
*mode);
+struct edid *drm_do_get_edid(struct drm_connector *connector,
+ int (*get_edid_block)(void *, u8 *buf, unsigned int, size_t),
+ void *data);
+
#endif /* __DRM_EDID_H__ */
--
2.0.4
[PATCH v2 7/9] video: Add ADV751[13] DT bindings documentation
The ADV7511, ADV7511W and ADV7513 are HDMI audio and video transmitters
compatible with HDMI 1.4 and DVI 1.0. They're described in DT using the
OF graph bindings and a list of custom properties pertaining to the
input video bus configuration.
Cc: devicetree at vger.kernel.org
Cc: Lars-Peter Clausen
Signed-off-by: Laurent Pinchart
---
Changes since v1:
- Clarify the adi,input-format DT property documentation
- Fixed typo
---
.../devicetree/bindings/video/adi,adv7511.txt | 88 ++
1 file changed, 88 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/adi,adv7511.txt
diff --git a/Documentation/devicetree/bindings/video/adi,adv7511.txt
b/Documentation/devicetree/bindings/video/adi,adv7511.txt
new file mode 100644
index ..96c25ee01501
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/adi,adv7511.txt
@@ -0,0 +1,88 @@
+Analog Device ADV7511(W)/13 HDMI Encoders
+-
+
+The ADV7511, ADV7511W and ADV7513 are HDMI audio and video transmitters
+compatible with HDMI 1.4 and DVI 1.0. They support color space conversion,
+S/PDIF, CEC and HDCP.
+
+Required properties:
+
+- compatible: Should be one of "adi,adv7511", "adi,adv7511w" or "adi,adv7513"
+- reg: I2C slave address
+
+The ADV7511 supports a large number of input data formats that differ by their
+color depth, color format, clock mode, bit justification and random
+arrangement of components on the data bus. The combination of the following
+properties describe the input and map directly to the video input tables of the
+ADV7511 datasheet that document all the supported combinations.
+
+- adi,input-depth: Number of bits per color component at the input (8, 10 or
+ 12).
+- adi,input-colorspace: The input color space, one of "rgb", "yuv422" or
+ "yuv444".
+- adi,input-clock: The input clock type, one of "1x" (one clock cycle per
+ pixel), "2x" (two clock cycles per pixel), "ddr" (one clock cycle per pixel,
+ data driven on both edges).
+
+The following input format properties are required except in "rgb 1x" and
+"yuv444 1x" modes, in which case they must not be specified.
+
+- adi,input-style: The input components arrangement variant (1, 2 or 3), as
+ listed in the input format tables in the datasheet.
+- adi,input-justification: The input bit justification ("left", "evenly",
+ "right").
+
+Optional properties:
+
+- interrupts: Specifier for the ADV7511 interrupt
+- pd-gpios: Specifier for the GPIO connected to the power down signal
+
+- adi,clock-delay: Video data clock delay relative to the pixel clock, in ps
+ (-1200 ps .. 1600 ps). Defaults to no delay.
+- adi,embedded-sync: The input uses synchronization signals embedded in the
+ data stream (similar to BT.656). Defaults to separate H/V synchronization
+ signals.
+
+Required nodes:
+
+The ADV7511 has two video ports. Their connections are modelled using the OF
+graph bindings specified in Documentation/devicetree/bindings/graph.txt.
+
+- Video port 0 for the RGB or YUV input
+- Video port 1 for the HDMI output
+
+
+Example
+---
+
+ adv7511w: hdmi at 39 {
+ compatible = "adi,adv7511w";
+ reg = <39>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
+
+ adi,input-depth = <8>;
+ adi,input-colorspace = "rgb";
+ adi,input-clock = "1x";
+ adi,input-style = <1>;
+ adi,input-justification = "evenly";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ adv7511w_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port at 1 {
+ reg = <1>;
+ adv7511_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
--
2.0.4
[Intel-gfx] [PATCH v3 05/11] drm/i915: remove intel_crtc_cursor_set_obj()
2014-10-07 Ville Syrj?l? :
> On Wed, Sep 24, 2014 at 02:20:26PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Merge it into the plane update_plane() callback and make other
> > users use the update_plane() functions instead.
> >
> > The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj()
> > so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane()
> > and merge both paths into one.
> >
> > Signed-off-by: Gustavo Padovan
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 221
> > +--
> > 1 file changed, 106 insertions(+), 115 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index f91a5b0..a583abd 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -8457,109 +8457,6 @@ static bool cursor_size_ok(struct drm_device *dev,
> > return true;
> > }
> >
> > -static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc,
> > -struct drm_i915_gem_object *obj,
> > -uint32_t width, uint32_t height)
> > -{
> > - struct drm_device *dev = crtc->dev;
> > - struct drm_i915_private *dev_priv = dev->dev_private;
> > - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > - enum pipe pipe = intel_crtc->pipe;
> > - unsigned old_width;
> > - uint32_t addr;
> > - int ret;
> > -
> > - /* if we want to turn off the cursor ignore width and height */
> > - if (!obj) {
> > - DRM_DEBUG_KMS("cursor off\n");
> > - addr = 0;
> > - mutex_lock(&dev->struct_mutex);
> > - goto finish;
> > - }
> > -
> > - /* we only need to pin inside GTT if cursor is non-phy */
> > - mutex_lock(&dev->struct_mutex);
> > - if (!INTEL_INFO(dev)->cursor_needs_physical) {
> > - unsigned alignment;
> > -
> > - /*
> > -* Global gtt pte registers are special registers which actually
> > -* forward writes to a chunk of system memory. Which means that
> > -* there is no risk that the register values disappear as soon
> > -* as we call intel_runtime_pm_put(), so it is correct to wrap
> > -* only the pin/unpin/fence and not more.
> > -*/
> > - intel_runtime_pm_get(dev_priv);
> > -
> > - /* Note that the w/a also requires 2 PTE of padding following
> > -* the bo. We currently fill all unused PTE with the shadow
> > -* page and so we should always have valid PTE following the
> > -* cursor preventing the VT-d warning.
> > -*/
> > - alignment = 0;
> > - if (need_vtd_wa(dev))
> > - alignment = 64*1024;
> > -
> > - ret = i915_gem_object_pin_to_display_plane(obj, alignment,
> > NULL);
> > - if (ret) {
> > - DRM_DEBUG_KMS("failed to move cursor bo into the
> > GTT\n");
> > - intel_runtime_pm_put(dev_priv);
> > - goto fail_locked;
> > - }
> > -
> > - ret = i915_gem_object_put_fence(obj);
> > - if (ret) {
> > - DRM_DEBUG_KMS("failed to release fence for cursor");
> > - intel_runtime_pm_put(dev_priv);
> > - goto fail_unpin;
> > - }
> > -
> > - addr = i915_gem_obj_ggtt_offset(obj);
> > -
> > - intel_runtime_pm_put(dev_priv);
> > - } else {
> > - int align = IS_I830(dev) ? 16 * 1024 : 256;
> > - ret = i915_gem_object_attach_phys(obj, align);
> > - if (ret) {
> > - DRM_DEBUG_KMS("failed to attach phys object\n");
> > - goto fail_locked;
> > - }
> > - addr = obj->phys_handle->busaddr;
> > - }
> > -
> > - finish:
> > - if (intel_crtc->cursor_bo) {
> > - if (!INTEL_INFO(dev)->cursor_needs_physical)
> > -
> > i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo);
> > - }
> > -
> > - i915_gem_track_fb(intel_crtc->cursor_bo, obj,
> > - INTEL_FRONTBUFFER_CURSOR(pipe));
> > - mutex_unlock(&dev->struct_mutex);
> > -
> > - old_width = intel_crtc->cursor_width;
> > -
> > - intel_crtc->cursor_addr = addr;
> > - intel_crtc->cursor_bo = obj;
> > - intel_crtc->cursor_width = width;
> > - intel_crtc->cursor_height = height;
> > -
> > - if (intel_crtc->active) {
> > - if (old_width != width)
> > - intel_update_watermarks(crtc);
> > - intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL);
> > - }
> > -
> > - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe));
> > -
> > - return 0;
> > -fail_unpin:
> > - i915_gem_object_unpin_from_display_plane(obj);
> > -fail_locked:
> > - mutex_unlock(&dev->struct_mutex);
> > - return ret;
> > -}
> > -
> >
[PATCH v4 1/5] drm/i915: create a prepare step for primary planes updates
From: Gustavo Padovan
Take out the pin_fb code so commit phase can't fail anymore.
Signed-off-by: Gustavo Padovan
Reviewed-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 35 ++-
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7d891e5..8530401 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11660,20 +11660,16 @@ intel_check_primary_plane(struct drm_plane *plane,
}
static int
-intel_commit_primary_plane(struct drm_plane *plane,
- struct intel_plane_state *state)
+intel_prepare_primary_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
{
struct drm_crtc *crtc = state->crtc;
struct drm_framebuffer *fb = state->fb;
struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc->pipe;
- struct drm_framebuffer *old_fb = plane->fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
- struct intel_plane *intel_plane = to_intel_plane(plane);
- struct drm_rect *src = &state->src;
int ret;
intel_crtc_wait_for_pending_flips(crtc);
@@ -11683,7 +11679,7 @@ intel_commit_primary_plane(struct drm_plane *plane,
return -EBUSY;
}
- if (plane->fb != fb) {
+ if (old_obj != obj) {
mutex_lock(&dev->struct_mutex);
ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
if (ret == 0)
@@ -11696,6 +11692,25 @@ intel_commit_primary_plane(struct drm_plane *plane,
}
}
+ return 0;
+}
+
+static void
+intel_commit_primary_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
+{
+ struct drm_crtc *crtc = state->crtc;
+ struct drm_framebuffer *fb = state->fb;
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ enum pipe pipe = intel_crtc->pipe;
+ struct drm_framebuffer *old_fb = plane->fb;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ struct drm_rect *src = &state->src;
+
crtc->primary->fb = fb;
crtc->x = src->x1;
crtc->y = src->y1;
@@ -11772,8 +11787,6 @@ intel_commit_primary_plane(struct drm_plane *plane,
intel_unpin_fb_obj(old_obj);
mutex_unlock(&dev->struct_mutex);
}
-
- return 0;
}
static int
@@ -11814,6 +11827,10 @@ intel_primary_plane_setplane(struct drm_plane *plane,
struct drm_crtc *crtc,
if (ret)
return ret;
+ ret = intel_prepare_primary_plane(plane, &state);
+ if (ret)
+ return ret;
+
intel_commit_primary_plane(plane, &state);
return 0;
--
1.9.3
[PATCH v4 2/5] drm/i915: create a prepare phase for sprite plane updates
From: Gustavo Padovan
take out pin_fb code so the commit phase can't fail anymore.
Signed-off-by: Gustavo Padovan
Reviewed-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_sprite.c | 63 +++--
1 file changed, 40 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 2c060ad..3631b0e 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1192,34 +1192,18 @@ intel_check_sprite_plane(struct drm_plane *plane,
}
static int
-intel_commit_sprite_plane(struct drm_plane *plane,
- struct intel_plane_state *state)
+intel_prepare_sprite_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
{
struct drm_device *dev = plane->dev;
struct drm_crtc *crtc = state->crtc;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- struct intel_plane *intel_plane = to_intel_plane(plane);
enum pipe pipe = intel_crtc->pipe;
struct drm_framebuffer *fb = state->fb;
- struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
- struct drm_i915_gem_object *obj = intel_fb->obj;
- struct drm_i915_gem_object *old_obj = intel_plane->obj;
- int crtc_x, crtc_y;
- unsigned int crtc_w, crtc_h;
- uint32_t src_x, src_y, src_w, src_h;
- struct drm_rect *dst = &state->dst;
- const struct drm_rect *clip = &state->clip;
- bool primary_enabled;
+ struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb);
int ret;
- /*
-* If the sprite is completely covering the primary plane,
-* we can disable the primary and save power.
-*/
- primary_enabled = !drm_rect_equals(dst, clip) ||
colorkey_enabled(intel_plane);
- WARN_ON(!primary_enabled && !state->visible && intel_crtc->active);
-
-
if (old_obj != obj) {
mutex_lock(&dev->struct_mutex);
@@ -1238,6 +1222,36 @@ intel_commit_sprite_plane(struct drm_plane *plane,
return ret;
}
+ return 0;
+}
+
+static void
+intel_commit_sprite_plane(struct drm_plane *plane,
+ struct intel_plane_state *state)
+{
+ struct drm_device *dev = plane->dev;
+ struct drm_crtc *crtc = state->crtc;
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ enum pipe pipe = intel_crtc->pipe;
+ struct drm_framebuffer *fb = state->fb;
+ struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_gem_object *obj = intel_fb->obj;
+ struct drm_i915_gem_object *old_obj = intel_plane->obj;
+ int crtc_x, crtc_y;
+ unsigned int crtc_w, crtc_h;
+ uint32_t src_x, src_y, src_w, src_h;
+ struct drm_rect *dst = &state->dst;
+ const struct drm_rect *clip = &state->clip;
+ bool primary_enabled;
+
+ /*
+* If the sprite is completely covering the primary plane,
+* we can disable the primary and save power.
+*/
+ primary_enabled = !drm_rect_equals(dst, clip) ||
colorkey_enabled(intel_plane);
+ WARN_ON(!primary_enabled && !state->visible && intel_crtc->active);
+
intel_plane->crtc_x = state->orig_dst.x1;
intel_plane->crtc_y = state->orig_dst.y1;
intel_plane->crtc_w = drm_rect_width(&state->orig_dst);
@@ -1298,8 +1312,6 @@ intel_commit_sprite_plane(struct drm_plane *plane,
intel_unpin_fb_obj(old_obj);
mutex_unlock(&dev->struct_mutex);
}
-
- return 0;
}
static int
@@ -1339,7 +1351,12 @@ intel_update_plane(struct drm_plane *plane, struct
drm_crtc *crtc,
if (ret)
return ret;
- return intel_commit_sprite_plane(plane, &state);
+ ret = intel_prepare_sprite_plane(plane, &state);
+ if (ret)
+ return ret;
+
+ intel_commit_sprite_plane(plane, &state);
+ return 0;
}
static int
--
1.9.3
[PATCH v4 3/5] drm/i915: use intel_fb_obj() macros to assign gem objects
From: Gustavo Padovan Use the macros makes the code cleaner and it also checks for a NULL fb. Signed-off-by: Gustavo Padovan Reviewed-by: Ville Syrj?l? --- drivers/gpu/drm/i915/intel_sprite.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c index 3631b0e..8b80d68 100644 --- a/drivers/gpu/drm/i915/intel_sprite.c +++ b/drivers/gpu/drm/i915/intel_sprite.c @@ -1032,8 +1032,7 @@ intel_check_sprite_plane(struct drm_plane *plane, struct intel_crtc *intel_crtc = to_intel_crtc(state->crtc); struct intel_plane *intel_plane = to_intel_plane(plane); struct drm_framebuffer *fb = state->fb; - struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); - struct drm_i915_gem_object *obj = intel_fb->obj; + struct drm_i915_gem_object *obj = intel_fb_obj(fb); int crtc_x, crtc_y; unsigned int crtc_w, crtc_h; uint32_t src_x, src_y, src_w, src_h; @@ -1235,9 +1234,8 @@ intel_commit_sprite_plane(struct drm_plane *plane, struct intel_plane *intel_plane = to_intel_plane(plane); enum pipe pipe = intel_crtc->pipe; struct drm_framebuffer *fb = state->fb; - struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb); - struct drm_i915_gem_object *obj = intel_fb->obj; - struct drm_i915_gem_object *old_obj = intel_plane->obj; + struct drm_i915_gem_object *obj = intel_fb_obj(fb); + struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); int crtc_x, crtc_y; unsigned int crtc_w, crtc_h; uint32_t src_x, src_y, src_w, src_h; -- 1.9.3
[PATCH v4 4/5] drm/i915: only flip frontbuffer if crtc is active
From: Gustavo Padovan There is no point in flipping a buffer for a disabled crtc. Signed-off-by: Gustavo Padovan --- drivers/gpu/drm/i915/intel_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 8530401..9a913f5 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8544,9 +8544,9 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc, if (old_width != width) intel_update_watermarks(crtc); intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL); - } - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe)); + intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe)); + } return 0; fail_unpin: -- 1.9.3
[PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj()
From: Gustavo Padovan
Merge it into the plane update_plane() callback and make other
users use the update_plane() functions instead.
The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj()
so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane()
and merge both paths into one.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 215 ---
1 file changed, 100 insertions(+), 115 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9a913f5..60ec165 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8453,109 +8453,6 @@ static bool cursor_size_ok(struct drm_device *dev,
return true;
}
-static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc,
-struct drm_i915_gem_object *obj,
-uint32_t width, uint32_t height)
-{
- struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- enum pipe pipe = intel_crtc->pipe;
- unsigned old_width;
- uint32_t addr;
- int ret;
-
- /* if we want to turn off the cursor ignore width and height */
- if (!obj) {
- DRM_DEBUG_KMS("cursor off\n");
- addr = 0;
- mutex_lock(&dev->struct_mutex);
- goto finish;
- }
-
- /* we only need to pin inside GTT if cursor is non-phy */
- mutex_lock(&dev->struct_mutex);
- if (!INTEL_INFO(dev)->cursor_needs_physical) {
- unsigned alignment;
-
- /*
-* Global gtt pte registers are special registers which actually
-* forward writes to a chunk of system memory. Which means that
-* there is no risk that the register values disappear as soon
-* as we call intel_runtime_pm_put(), so it is correct to wrap
-* only the pin/unpin/fence and not more.
-*/
- intel_runtime_pm_get(dev_priv);
-
- /* Note that the w/a also requires 2 PTE of padding following
-* the bo. We currently fill all unused PTE with the shadow
-* page and so we should always have valid PTE following the
-* cursor preventing the VT-d warning.
-*/
- alignment = 0;
- if (need_vtd_wa(dev))
- alignment = 64*1024;
-
- ret = i915_gem_object_pin_to_display_plane(obj, alignment,
NULL);
- if (ret) {
- DRM_DEBUG_KMS("failed to move cursor bo into the
GTT\n");
- intel_runtime_pm_put(dev_priv);
- goto fail_locked;
- }
-
- ret = i915_gem_object_put_fence(obj);
- if (ret) {
- DRM_DEBUG_KMS("failed to release fence for cursor");
- intel_runtime_pm_put(dev_priv);
- goto fail_unpin;
- }
-
- addr = i915_gem_obj_ggtt_offset(obj);
-
- intel_runtime_pm_put(dev_priv);
- } else {
- int align = IS_I830(dev) ? 16 * 1024 : 256;
- ret = i915_gem_object_attach_phys(obj, align);
- if (ret) {
- DRM_DEBUG_KMS("failed to attach phys object\n");
- goto fail_locked;
- }
- addr = obj->phys_handle->busaddr;
- }
-
- finish:
- if (intel_crtc->cursor_bo) {
- if (!INTEL_INFO(dev)->cursor_needs_physical)
-
i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo);
- }
-
- i915_gem_track_fb(intel_crtc->cursor_bo, obj,
- INTEL_FRONTBUFFER_CURSOR(pipe));
- mutex_unlock(&dev->struct_mutex);
-
- old_width = intel_crtc->cursor_width;
-
- intel_crtc->cursor_addr = addr;
- intel_crtc->cursor_bo = obj;
- intel_crtc->cursor_width = width;
- intel_crtc->cursor_height = height;
-
- if (intel_crtc->active) {
- if (old_width != width)
- intel_update_watermarks(crtc);
- intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL);
-
- intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe));
- }
-
- return 0;
-fail_unpin:
- i915_gem_object_unpin_from_display_plane(obj);
-fail_locked:
- mutex_unlock(&dev->struct_mutex);
- return ret;
-}
-
static void intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
u16 *blue, uint32_t start, uint32_t size)
{
@@ -11906,7 +11803,8 @@ intel_cursor_plane_disable(struct drm_plane *plane)
BUG_ON(!plane->crtc);
- return inte
[PATCH v2 6/9] drm: Decouple EDID parsing from I2C adapter
On Fri, Oct 24, 2014 at 2:58 PM, Laurent Pinchart
wrote:
> --- a/include/drm/drm_edid.h
> +++ b/include/drm/drm_edid.h
> @@ -279,4 +279,8 @@ int
> drm_hdmi_vendor_infoframe_from_display_mode(struct hdmi_vendor_infoframe
> *frame,
> const struct drm_display_mode
> *mode);
>
> +struct edid *drm_do_get_edid(struct drm_connector *connector,
> + int (*get_edid_block)(void *, u8 *buf, unsigned int, size_t),
It doesn't hurt to add parameter names for all parameters, as hints
for implementors.
> + void *data);
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
[Intel-gfx] [PATCH v3 11/11] drm/i915: remove intel_pipe_set_base()
On Fri, Oct 24, 2014 at 02:59:44PM +0100, Gustavo Padovan wrote:
> 2014-10-07 Ville Syrj?l? :
>
> > On Wed, Sep 24, 2014 at 02:20:32PM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > After some refactor intel_primary_plane_setplane() does the same
> > > as intel_pipe_set_base() so we can get rid of it and replace the calls
> > > with intel_primary_plane_setplane().
> > >
> > > v2: take Ville's comments:
> > > - get the right arguments for update_plane()
> > > - use drm_crtc_get_hv_timing()
> > >
> > > Signed-off-by: Gustavo Padovan
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 89
> > >
> > > 1 file changed, 18 insertions(+), 71 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 9dd4952..f7c2e5f 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -2857,74 +2857,6 @@ static void intel_update_pipe_size(struct
> > > intel_crtc *crtc)
> > > crtc->config.pipe_src_h = adjusted_mode->crtc_vdisplay;
> > > }
> > >
> > > -static int
> > > -intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
> > > - struct drm_framebuffer *fb)
> > > -{
> > > - struct drm_device *dev = crtc->dev;
> > > - struct drm_i915_private *dev_priv = dev->dev_private;
> > > - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > - enum pipe pipe = intel_crtc->pipe;
> > > - struct drm_framebuffer *old_fb = crtc->primary->fb;
> > > - struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> > > - struct drm_i915_gem_object *old_obj = intel_fb_obj(old_fb);
> > > - int ret;
> > > -
> > > - if (intel_crtc_has_pending_flip(crtc)) {
> > > - DRM_ERROR("pipe is still busy with an old pageflip\n");
> > > - return -EBUSY;
> > > - }
> > > -
> > > - /* no fb bound */
> > > - if (!fb) {
> > > - DRM_ERROR("No FB bound\n");
> > > - return 0;
> > > - }
> > > -
> > > - if (intel_crtc->plane > INTEL_INFO(dev)->num_pipes) {
> > > - DRM_ERROR("no plane for crtc: plane %c, num_pipes %d\n",
> > > - plane_name(intel_crtc->plane),
> > > - INTEL_INFO(dev)->num_pipes);
> > > - return -EINVAL;
> > > - }
> > > -
> > > - mutex_lock(&dev->struct_mutex);
> > > - ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
> > > - if (ret == 0)
> > > - i915_gem_track_fb(old_obj, obj,
> > > - INTEL_FRONTBUFFER_PRIMARY(pipe));
> > > - mutex_unlock(&dev->struct_mutex);
> > > - if (ret != 0) {
> > > - DRM_ERROR("pin & fence failed\n");
> > > - return ret;
> > > - }
> > > -
> > > - intel_update_pipe_size(intel_crtc);
> > > -
> > > - dev_priv->display.update_primary_plane(crtc, fb, x, y);
> > > -
> > > - if (intel_crtc->active)
> > > - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_PRIMARY(pipe));
> > > -
> > > - crtc->primary->fb = fb;
> > > - crtc->x = x;
> > > - crtc->y = y;
> > > -
> > > - if (old_fb) {
> > > - if (intel_crtc->active && old_fb != fb)
> > > - intel_wait_for_vblank(dev, intel_crtc->pipe);
> > > - mutex_lock(&dev->struct_mutex);
> > > - intel_unpin_fb_obj(old_obj);
> > > - mutex_unlock(&dev->struct_mutex);
> > > - }
> > > -
> > > - mutex_lock(&dev->struct_mutex);
> > > - intel_update_fbc(dev);
> > > - mutex_unlock(&dev->struct_mutex);
> > > -
> > > - return 0;
> > > -}
> > > -
> > > static void intel_fdi_normal_train(struct drm_crtc *crtc)
> > > {
> > > struct drm_device *dev = crtc->dev;
> > > @@ -9681,6 +9613,8 @@ static int intel_crtc_commit_page_flip(struct
> > > drm_crtc *crtc,
> > > struct drm_framebuffer *old_fb = crtc->primary->fb;
> > > struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> > > struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > + struct drm_plane *primary = crtc->primary;
> > > + struct intel_plane *intel_plane = to_intel_plane(primary);
> > > enum pipe pipe = intel_crtc->pipe;
> > > struct intel_unpin_work *work;
> > > struct intel_engine_cs *ring;
> > > @@ -9822,7 +9756,15 @@ free_work:
> > > if (ret == -EIO) {
> > > out_hang:
> > > intel_crtc_wait_for_pending_flips(crtc);
> > > - ret = intel_pipe_set_base(crtc, crtc->x, crtc->y, fb);
> > > + ret = primary->funcs->update_plane(primary, crtc, fb,
> > > +intel_plane->crtc_x,
> > > +intel_plane->crtc_y,
> > > +intel_plane->crtc_h,
> > > +intel_plane->crtc_w,
> > > +intel_plane->src_x,
> > > +intel_plane->src_y,
> > > +intel_plane->src_h,
> > > +intel_plane->src_w);
> > >
[PULL] drm-intel-next, take 3
Hi Dave, Ok, new attempt, this time around with full ppgtt disabled again. drm-intel-next-2014-10-03: - first batch of skl stage 1 enabling - fixes from Rodrigo to the PSR, fbc and sink crc code - kerneldoc for the frontbuffer tracking code, runtime pm code and the basic interrupt enable/disable functions - smaller stuff all over drm-intel-next-2014-09-19: - bunch more i830M fixes from Ville - full ppgtt now again enabled by default - more ppgtt fixes from Michel Thierry and Chris Wilson - plane config work from Gustavo Padovan - spinlock clarifications - piles of smaller improvements all over, as usual Cheers, Daniel The following changes since commit 07c338ce98263a5af631b991dd8f96cff6ca2548: drm/i915: fix short vs. long hpd detection (2014-10-16 15:00:28 +0300) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-next-2014-10-03-no-ppgtt for you to fetch changes up to cacc6c837b799b058d59d2af02c11140640cc1d2: Revert "drm/i915: Enable full PPGTT on gen7" (2014-10-24 16:30:14 +0200) Brad Volkin (2): drm/i915: Re-enable the command parser when using PPGTT drm/i915: Log a message when rejecting LRM to OACONTROL Chris Wilson (3): drm/i915: Remove dead code, i915_gem_verify_gtt drm/i915: Inline feature detection into sanitize_enable_ppgtt drm/i915: Remove the duplicated logic between the two shrink phases Daisy Sun (1): drm/i915/skl: SKL FBC enablement Damien Lespiau (31): drm/i915/skl: Add the Skylake PCI ids drm/i915/skl: Add an IS_GEN9() define drm/i915/skl: Fence registers on SKL are the same as SNB drm/i915/skl: Provide a placeholder for init_clock_gating() drm/i915/skl: Skylake shares the interrupt logic with Broadwell drm/i915/skl: Framebuffers need to be aligned to 256KB on Skylake drm/i915/skl: Implement the new update_plane() for primary planes drm/i915/skl: Don't create a VGA connector on Skylake drm/i915/skl: Don't try to read out the PCH transcoder state if not present drm/i915/skl: Program the DDI buffer translation tables drm/i915/skl: Add support for DP voltage swings and pre-emphasis drm/i915/skl: Skylake moves AUX_CTL from PCH to CPU drm/i915/skl: Add the additional graphics stolen sizes drm/i915/skl: gen9 uses the same bind_vma() vfuncs as gen6+ drm/i915/skl: Implement the get_aux_clock_divider() DP vfunc drm/i915/skl: Provide a get_aux_send_ctl() vfunc for skylake drm/i915/skl: Initialize PPGTT like gen8 drm/i915/skl: Allow the reg_read ioctl to return RCS_TIMESTAMP drm/i915/skl: report the same INSTDONE registers as gen8 drm/i915/skl: Report the PDP regs as in gen8 drm/i915/skl: SKL shares the same underrun interrupt as BDW drm/i915/skl: Adjust the display engine interrupts drm/i915/skl: Implement WaDisableSDEUnitClockGating:skl drm/i915/skl: Implement Wa4x4STCOptimizationDisable:skl drm/i915/skl: Implement WaDisableDgMirrorFixInHalfSliceChicken5:skl drm/i915/skl: Skylake has 2 "sprite" planes per pipe drm/i915/skl: Implement drm_plane vfuncs drm/i915/skl: Adjust assert_sprites_disabled() drm/i915/skl: Introduce a I915_MAX_PLANES macro drm/i915/skl: Introduce intel_num_planes() drm/i915/skl: Move gen9 pm initialization into its own branch Daniel Vetter (37): drm/i915: WARN if interrupts aren't on in en/disable_pipestat drm/i915: Restore resume irq ordering comment drm/i915: Drop get/put_pages for scratch page agp/intel-gtt: Remove get/put_pages drm/i915: Fix irq checks in ring->irq_get/put functions drm/i915: Convert backlight_lock to a mutex drm/i915: Use generic vblank wait drm/i915: static inline for intel_wait_for_vblank drm/i915: Clarify event_lock locking, process context drm/i915: Clarify event_lock locking, irq&mixed context drm/i915: Clarify gpu_error.lock locking drm/i915: Clarify irq_lock locking, intel_tv_detect drm/i915: Clarify irq_lock locking, work functions drm/i915: Clarify irq_lock locking, interrupt install/uninstall drm/i915: Clarify irq_lock locking, irq handlers drm/i915: Clarify irq_lock locking, special cases drm/i915: Clarify uncore.lock locking drm/i915: Clarify mmio_flip_lock locking drm/i915: Update DRIVER_DATE to 20140919 drm/i915: DocBook integration for frontbuffer tracking Merge branch 'topic/skl-stage1' into drm-intel-next-queued drm/i915: Tighting frontbuffer tracking around flips drm/i915: spelling fixes for frontbuffer tracking kerneldoc drm/i915: Remove intel_modeset_suspend_hw drm/i915: Extract intel_runtime_pm.c drm/i915: Bikeshed rpm functions name a bit. drm/i915: Move intel_display_set_init_power to intel_runtime_pm.c drm/i915: Call ru
[Intel-gfx] [PATCH v3 05/11] drm/i915: remove intel_crtc_cursor_set_obj()
On Fri, Oct 24, 2014 at 02:23:35PM +0100, Gustavo Padovan wrote:
> 2014-10-07 Ville Syrj?l? :
>
> > On Wed, Sep 24, 2014 at 02:20:26PM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > Merge it into the plane update_plane() callback and make other
> > > users use the update_plane() functions instead.
> > >
> > > The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj()
> > > so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane()
> > > and merge both paths into one.
> > >
> > > Signed-off-by: Gustavo Padovan
> > > ---
> > > drivers/gpu/drm/i915/intel_display.c | 221
> > > +--
> > > 1 file changed, 106 insertions(+), 115 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index f91a5b0..a583abd 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -8457,109 +8457,6 @@ static bool cursor_size_ok(struct drm_device *dev,
> > > return true;
> > > }
> > >
> > > -static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc,
> > > - struct drm_i915_gem_object *obj,
> > > - uint32_t width, uint32_t height)
> > > -{
> > > - struct drm_device *dev = crtc->dev;
> > > - struct drm_i915_private *dev_priv = dev->dev_private;
> > > - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > - enum pipe pipe = intel_crtc->pipe;
> > > - unsigned old_width;
> > > - uint32_t addr;
> > > - int ret;
> > > -
> > > - /* if we want to turn off the cursor ignore width and height */
> > > - if (!obj) {
> > > - DRM_DEBUG_KMS("cursor off\n");
> > > - addr = 0;
> > > - mutex_lock(&dev->struct_mutex);
> > > - goto finish;
> > > - }
> > > -
> > > - /* we only need to pin inside GTT if cursor is non-phy */
> > > - mutex_lock(&dev->struct_mutex);
> > > - if (!INTEL_INFO(dev)->cursor_needs_physical) {
> > > - unsigned alignment;
> > > -
> > > - /*
> > > - * Global gtt pte registers are special registers which actually
> > > - * forward writes to a chunk of system memory. Which means that
> > > - * there is no risk that the register values disappear as soon
> > > - * as we call intel_runtime_pm_put(), so it is correct to wrap
> > > - * only the pin/unpin/fence and not more.
> > > - */
> > > - intel_runtime_pm_get(dev_priv);
> > > -
> > > - /* Note that the w/a also requires 2 PTE of padding following
> > > - * the bo. We currently fill all unused PTE with the shadow
> > > - * page and so we should always have valid PTE following the
> > > - * cursor preventing the VT-d warning.
> > > - */
> > > - alignment = 0;
> > > - if (need_vtd_wa(dev))
> > > - alignment = 64*1024;
> > > -
> > > - ret = i915_gem_object_pin_to_display_plane(obj, alignment,
> > > NULL);
> > > - if (ret) {
> > > - DRM_DEBUG_KMS("failed to move cursor bo into the
> > > GTT\n");
> > > - intel_runtime_pm_put(dev_priv);
> > > - goto fail_locked;
> > > - }
> > > -
> > > - ret = i915_gem_object_put_fence(obj);
> > > - if (ret) {
> > > - DRM_DEBUG_KMS("failed to release fence for cursor");
> > > - intel_runtime_pm_put(dev_priv);
> > > - goto fail_unpin;
> > > - }
> > > -
> > > - addr = i915_gem_obj_ggtt_offset(obj);
> > > -
> > > - intel_runtime_pm_put(dev_priv);
> > > - } else {
> > > - int align = IS_I830(dev) ? 16 * 1024 : 256;
> > > - ret = i915_gem_object_attach_phys(obj, align);
> > > - if (ret) {
> > > - DRM_DEBUG_KMS("failed to attach phys object\n");
> > > - goto fail_locked;
> > > - }
> > > - addr = obj->phys_handle->busaddr;
> > > - }
> > > -
> > > - finish:
> > > - if (intel_crtc->cursor_bo) {
> > > - if (!INTEL_INFO(dev)->cursor_needs_physical)
> > > -
> > > i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo);
> > > - }
> > > -
> > > - i915_gem_track_fb(intel_crtc->cursor_bo, obj,
> > > - INTEL_FRONTBUFFER_CURSOR(pipe));
> > > - mutex_unlock(&dev->struct_mutex);
> > > -
> > > - old_width = intel_crtc->cursor_width;
> > > -
> > > - intel_crtc->cursor_addr = addr;
> > > - intel_crtc->cursor_bo = obj;
> > > - intel_crtc->cursor_width = width;
> > > - intel_crtc->cursor_height = height;
> > > -
> > > - if (intel_crtc->active) {
> > > - if (old_width != width)
> > > - intel_update_watermarks(crtc);
> > > - intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL);
> > > - }
> > > -
> > > - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe));
> > > -
> > > - return 0;
> > > -fa
[PATCH v4 4/5] drm/i915: only flip frontbuffer if crtc is active
On Fri, Oct 24, 2014 at 02:51:34PM +0100, Gustavo Padovan wrote: > From: Gustavo Padovan > > There is no point in flipping a buffer for a disabled crtc. That thing doesn't actually flip but just signal the frontbuffer tracking code that either has just flipped or is going to real soon now (tm). But yeah, still makes no sense when the entire pipe is off, so: Reviewed-by: Ville Syrj?l? > > Signed-off-by: Gustavo Padovan > --- > drivers/gpu/drm/i915/intel_display.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 8530401..9a913f5 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -8544,9 +8544,9 @@ static int intel_crtc_cursor_set_obj(struct drm_crtc > *crtc, > if (old_width != width) > intel_update_watermarks(crtc); > intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL); > - } > > - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe)); > + intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe)); > + } > > return 0; > fail_unpin: > -- > 1.9.3 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Ville Syrj?l? Intel OTC
[Intel-gfx] [PATCH v4 5/5] drm/i915: remove intel_crtc_cursor_set_obj()
On Fri, Oct 24, 2014 at 02:51:35PM +0100, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Merge it into the plane update_plane() callback and make other
> users use the update_plane() functions instead.
>
> The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj()
> so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane()
> and merge both paths into one.
>
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/i915/intel_display.c | 215
> ---
> 1 file changed, 100 insertions(+), 115 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 9a913f5..60ec165 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8453,109 +8453,6 @@ static bool cursor_size_ok(struct drm_device *dev,
> return true;
> }
>
> -static int intel_crtc_cursor_set_obj(struct drm_crtc *crtc,
> - struct drm_i915_gem_object *obj,
> - uint32_t width, uint32_t height)
> -{
> - struct drm_device *dev = crtc->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> - enum pipe pipe = intel_crtc->pipe;
> - unsigned old_width;
> - uint32_t addr;
> - int ret;
> -
> - /* if we want to turn off the cursor ignore width and height */
> - if (!obj) {
> - DRM_DEBUG_KMS("cursor off\n");
> - addr = 0;
> - mutex_lock(&dev->struct_mutex);
> - goto finish;
> - }
> -
> - /* we only need to pin inside GTT if cursor is non-phy */
> - mutex_lock(&dev->struct_mutex);
> - if (!INTEL_INFO(dev)->cursor_needs_physical) {
> - unsigned alignment;
> -
> - /*
> - * Global gtt pte registers are special registers which actually
> - * forward writes to a chunk of system memory. Which means that
> - * there is no risk that the register values disappear as soon
> - * as we call intel_runtime_pm_put(), so it is correct to wrap
> - * only the pin/unpin/fence and not more.
> - */
> - intel_runtime_pm_get(dev_priv);
> -
> - /* Note that the w/a also requires 2 PTE of padding following
> - * the bo. We currently fill all unused PTE with the shadow
> - * page and so we should always have valid PTE following the
> - * cursor preventing the VT-d warning.
> - */
> - alignment = 0;
> - if (need_vtd_wa(dev))
> - alignment = 64*1024;
> -
> - ret = i915_gem_object_pin_to_display_plane(obj, alignment,
> NULL);
> - if (ret) {
> - DRM_DEBUG_KMS("failed to move cursor bo into the
> GTT\n");
> - intel_runtime_pm_put(dev_priv);
> - goto fail_locked;
> - }
> -
> - ret = i915_gem_object_put_fence(obj);
> - if (ret) {
> - DRM_DEBUG_KMS("failed to release fence for cursor");
> - intel_runtime_pm_put(dev_priv);
> - goto fail_unpin;
> - }
> -
> - addr = i915_gem_obj_ggtt_offset(obj);
> -
> - intel_runtime_pm_put(dev_priv);
> - } else {
> - int align = IS_I830(dev) ? 16 * 1024 : 256;
> - ret = i915_gem_object_attach_phys(obj, align);
> - if (ret) {
> - DRM_DEBUG_KMS("failed to attach phys object\n");
> - goto fail_locked;
> - }
> - addr = obj->phys_handle->busaddr;
> - }
> -
> - finish:
> - if (intel_crtc->cursor_bo) {
> - if (!INTEL_INFO(dev)->cursor_needs_physical)
> -
> i915_gem_object_unpin_from_display_plane(intel_crtc->cursor_bo);
> - }
> -
> - i915_gem_track_fb(intel_crtc->cursor_bo, obj,
> - INTEL_FRONTBUFFER_CURSOR(pipe));
> - mutex_unlock(&dev->struct_mutex);
> -
> - old_width = intel_crtc->cursor_width;
> -
> - intel_crtc->cursor_addr = addr;
> - intel_crtc->cursor_bo = obj;
> - intel_crtc->cursor_width = width;
> - intel_crtc->cursor_height = height;
> -
> - if (intel_crtc->active) {
> - if (old_width != width)
> - intel_update_watermarks(crtc);
> - intel_crtc_update_cursor(crtc, intel_crtc->cursor_bo != NULL);
> -
> - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_CURSOR(pipe));
> - }
> -
> - return 0;
> -fail_unpin:
> - i915_gem_object_unpin_from_display_plane(obj);
> -fail_locked:
> - mutex_unlock(&dev->struct_mutex);
> - return ret;
> -}
> -
> static void intel_crtc_gamma_set(struct drm_crtc *crtc, u16 *red, u16 *green,
>u16 *bl
[Bug 84944] tearing on radeonsi vdpau deinterlacer
https://bugs.freedesktop.org/show_bug.cgi?id=84944 --- Comment #22 from warpme at o2.pl --- (In reply to Michel D?nzer from comment #21) > (In reply to warpme from comment #20) > > [1031252.040] DRI2CanFlip: Window clipList doesn\'t match root window > > dimensions: > > [1031252.040] Window clipList extents: (0, 0)-(1920, 1078) > > [1031252.040] Root window extents: (0, 0)-(1920, 1080) > > Looks like either the MythTV output window is only 1078 pixels high, or the > bottom two rows of it are covered by another window. Can you run xwininfo > while there is tearing in MythTV, click on the MythTV output window, and > provide the output from xwininfo? Pls find xwininfo output: GUI: xwininfo: Window id: 0x163 "MythTV Frontend" Absolute upper-left X: 0 Absolute upper-left Y: 0 Relative upper-left X: 0 Relative upper-left Y: 0 Width: 1920 Height: 1080 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 1 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +0+0 --2+0 --2--2 +0--2 -geometry 1920x1080+0+0 --- playback tv of interlaced recording xwininfo: Window id: 0x163 "MythTV Frontend" Absolute upper-left X: -1 Absolute upper-left Y: -1 Relative upper-left X: -1 Relative upper-left Y: -1 Width: 1920 Height: 1078 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 1 Class: InputOutput Colormap: 0x20 (installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsViewable Override Redirect State: no Corners: +-1+-1 --1+-1 --1-1 +-1-1 -geometry 1920x1078+-1+-1 I see indeed playback is within 1920x1078. It looks however that only glamor starts to have tearing by this. Accordingly to comment8 it looks like also other players also behave in such way... -- 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/20141024/6de8379d/attachment.html>
[Bug 84500] [radeonsi] radeon 0000:01:00.0: Packet0 not allowed!
https://bugs.freedesktop.org/show_bug.cgi?id=84500 --- Comment #30 from Maciej --- Imagine bug like this happening on Windows, customers would go nuts and it would be fixed asap by AMD... But hey, Linux is not second class citizen, right? -- 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/20141024/696d7e8f/attachment.html>
[PATCH 1/2] drm: make sure visible is set to false if fb is null
From: Gustavo Padovan
We can't let visible set true while the fb is null, some places of
the code only check for visible to base its decisions.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/drm_plane_helper.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_plane_helper.c
b/drivers/gpu/drm/drm_plane_helper.c
index 827ec1a..fe4d1fb 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -127,6 +127,11 @@ int drm_plane_helper_check_update(struct drm_plane *plane,
return -ERANGE;
}
+ if (!fb) {
+ *visible = false;
+ return 0;
+ }
+
*visible = drm_rect_clip_scaled(src, dest, clip, hscale, vscale);
if (!*visible)
/*
--
1.9.3
[PATCH 2/2] drm/i915: remove unneeded visible check
From: Gustavo Padovan
The fb check introduced to drm_plane_helper_check_update() just make this
check impossible to branch in.
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ef2107f..5372b73 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11484,23 +11484,12 @@ intel_check_primary_plane(struct drm_plane *plane,
struct drm_rect *dest = &state->dst;
struct drm_rect *src = &state->src;
const struct drm_rect *clip = &state->clip;
- int ret;
-
- ret = drm_plane_helper_check_update(plane, crtc, fb,
- src, dest, clip,
- DRM_PLANE_HELPER_NO_SCALING,
- DRM_PLANE_HELPER_NO_SCALING,
- false, true, &state->visible);
- if (ret)
- return ret;
-
- /* no fb bound */
- if (state->visible && !fb) {
- DRM_ERROR("No FB bound\n");
- return -EINVAL;
- }
- return 0;
+ return drm_plane_helper_check_update(plane, crtc, fb,
+src, dest, clip,
+DRM_PLANE_HELPER_NO_SCALING,
+DRM_PLANE_HELPER_NO_SCALING,
+false, true, &state->visible);
}
static int
--
1.9.3
[Bug 83461] hdmi screen flicker/unusable
https://bugzilla.kernel.org/show_bug.cgi?id=83461 --- Comment #13 from Christian K?nig --- (In reply to kb from comment #12) > note xrandr is on good kernel, dmesg in on bad Those outputs should work fine. Going to make a patch for this, but this might take a while. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 85107] A10-7800: Boot problems (CPU stuck) and dpm not working correctly
https://bugs.freedesktop.org/show_bug.cgi?id=85107 --- Comment #13 from Marcel Witte --- Thanks for the patch. I still need radeon.bapm=0 to boot properly, but with setting pi->enable_nb_dpm = false; the clock is getting higher and so I have the full performance. Finally I can watch HD videos with VDPAU now :) I run this tests using kernel 3.18-rc1. I do not have looked at the code further, that is the consequence of this setting? Could there be any matching BIOS setting? How can I further debug why my system is needing this change? -- 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/20141024/a847d012/attachment.html>
[PATCH] regulator: stub out devm_regulator_get_exclusive
On Fri, Oct 24, 2014 at 4:11 PM, Mark Brown wrote: > On Fri, Oct 24, 2014 at 02:15:11PM -0500, Felipe Balbi wrote: >> If we don't stup that call out, we will have >> build failures for any drivers using that function >> when .config happens to have CONFIG_REGULATOR=n. >> >> One such case below, found with randconfig >> >> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c: In function ?mdp4_kms_init?: >> drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:2: error: implicit declaration \ > > As previously and repeatedly reported the regulator usage in this driver > appears extremely problematic, among these problems is that it almost > certainly has no sensible reason to be using regulator_get_exclusive() > or any variant of it. Sadly every time it's been raised with the video > people they've completely ignored the mail so here we are. oh, looks like a case of overambitious mailing list filter rules.. I did not see the earlier threads on the topic. iirc, I was using _get_exclusive() in a few places where I wanted to be sure not to get dummy-regulator in cases where I should -EPROBE_DEFER instead (since probe order with DT is slightly hilarious, and since I depend on a few other drivers I end up deferring at least a couple times at boot)... I don't quite remember the details. But afaict regulator_get() still allows dummy-regulator, which is what I specifically don't want. If you have a recommendation for a better way, I am all ears. BR, -R > Right now not having the stub seems to only be affecting buggy users > (which given the use cases for _exclusive() isn't *that* surprising) so > I'm more inclined to leave this there in the hope that the users get > fixed or we can at least get some sort of dialogue with the relevant > maintainers.
[PATCH] regulator: stub out devm_regulator_get_exclusive
On Fri, Oct 24, 2014 at 5:18 PM, Mark Brown wrote: > On Fri, Oct 24, 2014 at 04:36:24PM -0400, Rob Clark wrote: > >> iirc, I was using _get_exclusive() in a few places where I wanted to >> be sure not to get dummy-regulator in cases where I should >> -EPROBE_DEFER instead (since probe order with DT is slightly >> hilarious, and since I depend on a few other drivers I end up >> deferring at least a couple times at boot)... I don't quite remember >> the details. But afaict regulator_get() still allows dummy-regulator, >> which is what I specifically don't want. > > No, this is actually making things worse. You will only get a dummy > regulator from regulator_get() if no regulator at all is mapped in the > DT, if one is mapped then you'll always get either an -EPROBE_DEFER or > the real regulator. Right now the driver is broken with respect to > -EPROBE_DEFER since it just completely ignores the error code and > carries on happily if any error is returned which means that the > behaviour is going to be unstable on any given system, what happens will > depend on probe order which could in turn depend on what's been built > modular and so on. Oh, you are only looking at the one in mdp4_kms_init(), which could possibly be a simple regulator_get(). Look instead at the ones in hdmi_init(), where I need to know whether to defer or not. At one point I was having a problem getting dummy regulators with regulator_get() but that could have been a symptom of another problem. I will re-try regulator_get() next time I am working on the kernel part of the driver.. The mdp4_kms->vdd logic is a bit of a hack right now, since we are missing a driver upstream for that regulator (and just relying on bootloader to leave it on for us). BR, -R > As far as I can tell the only thing the driver does with the regulator > it's grabbing exclusively is enable it in probe() and that's going to > work just as well with the dummy regulator anyway so I can't see any > reason to worry if the driver is getting one. > >> If you have a recommendation for a better way, I am all ears. > > Just use regulator_get() (or better, devm_regulator_get()) and pay > attention to the errors. The driver should also disable the regulator > on remove and I'd be surprised if the other two regulators shouldn't be > using a normal _get() too. If there is a good reason to use _optional() > then the code should be changed to use ERR_PTR() rather than NULL to > check for missing regulators and the driver needs to keep them enabled > as long as it's using them. > > Given that the two optional regulators are only set to one specific > value it's a bit surprising that the DT doesn't do this but I guess it's > possible there could be broken DTs out there that do give permission for > set_voltage() for a range rather than specifying the correct voltage.
[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance
https://bugs.freedesktop.org/show_bug.cgi?id=82201 --- Comment #38 from Sebastian Parborg --- Kai, I have an 290x and I'm having the same problem as you. However I do not have windows installed at all. So I think we can rule that one out. For me it seem like the card loses the ability to reclock after a while. However I have regained the reclocking ability by rebooting to use fgrlx and then reboot back to use radeon... I'm just as confused as you are why it stops working. :S -- 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/20141024/c72e231e/attachment.html>
[Bug 82201] [HAWAII] GPU doesn't reclock, poor 3D performance
https://bugs.freedesktop.org/show_bug.cgi?id=82201 --- Comment #39 from Sebastian Parborg --- I take the fglrx stuff back. Seems like I were lucky the times that it worked... -- 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/20141024/da421176/attachment.html>
[PATCH] allow 32bpp framebuffers for cirrus drm
On Tue, Oct 7, 2014 at 12:49 PM, Zach Reizner wrote:
> This patch allows framebuffers for cirrus to be created with
> 32bpp pixel formats provided that they do not violate certain
> restrictions of the cirrus hardware.
>
> Signed-off-by: Zach Reizner
>
Reviewed-by: St?phane Marchesin
Dave, Adam: are you ok with this patch?
St?phane
> ---
> drivers/gpu/drm/cirrus/cirrus_drv.h | 2 ++
> drivers/gpu/drm/cirrus/cirrus_fbdev.c | 4 +++-
> drivers/gpu/drm/cirrus/cirrus_main.c | 22 --
> 3 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h
> b/drivers/gpu/drm/cirrus/cirrus_drv.h
> index 401c890..fac475c 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_drv.h
> +++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
> @@ -208,6 +208,8 @@ int cirrus_framebuffer_init(struct drm_device *dev,
> struct drm_mode_fb_cmd2 *mode_cmd,
> struct drm_gem_object *obj);
>
> +bool cirrus_check_framebuffer(int width, int height, int bpp, int pitch);
> +
> /* cirrus_display.c */
> int cirrus_modeset_init(struct cirrus_device *cdev);
> void cirrus_modeset_fini(struct cirrus_device *cdev);
> diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> index 2a135f2..4a0756c 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
> @@ -146,8 +146,10 @@ static int cirrusfb_create_object(struct cirrus_fbdev
> *afbdev,
> int ret = 0;
> drm_fb_get_bpp_depth(mode_cmd->pixel_format, &depth, &bpp);
>
> - if (bpp > 24)
> + if (!cirrus_check_framebuffer(mode_cmd->width, mode_cmd->height,
> bpp,
> + mode_cmd->pitches[0]))
> return -EINVAL;
> +
> size = mode_cmd->pitches[0] * mode_cmd->height;
> ret = cirrus_gem_create(dev, size, true, &gobj);
> if (ret)
> diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
> b/drivers/gpu/drm/cirrus/cirrus_main.c
> index 99c1983..029f9e9 100644
> --- a/drivers/gpu/drm/cirrus/cirrus_main.c
> +++ b/drivers/gpu/drm/cirrus/cirrus_main.c
> @@ -55,8 +55,9 @@ cirrus_user_framebuffer_create(struct drm_device *dev,
> u32 bpp, depth;
>
> drm_fb_get_bpp_depth(mode_cmd->pixel_format, &depth, &bpp);
> - /* cirrus can't handle > 24bpp framebuffers at all */
> - if (bpp > 24)
> +
> + if (!cirrus_check_framebuffer(mode_cmd->width, mode_cmd->height,
> + bpp, mode_cmd->pitches[0]))
> return ERR_PTR(-EINVAL);
>
> obj = drm_gem_object_lookup(dev, filp, mode_cmd->handles[0]);
> @@ -307,3 +308,20 @@ out_unlock:
> return ret;
>
> }
> +
> +bool cirrus_check_framebuffer(int width, int height, int bpp, int pitch)
> +{
> + const int max_pitch = 0x1FF << 3; /* (4096 - 1) & ~111b bytes */
> + const int max_size = 0x40; /* 4MB */
> +
> + if (bpp > 32)
> + return false;
> +
> + if (pitch > max_pitch)
> + return false;
> +
> + if (pitch * height > max_size)
> + return false;
> +
> + return true;
> +}
> --
> 2.1.0.rc2.206.gedb03e5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141024/38e2344c/attachment-0001.html>
[Intel-gfx] [PATCH v3 11/11] drm/i915: remove intel_pipe_set_base()
2014-10-07 Ville Syrj?l? :
> On Wed, Sep 24, 2014 at 02:20:32PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > After some refactor intel_primary_plane_setplane() does the same
> > as intel_pipe_set_base() so we can get rid of it and replace the calls
> > with intel_primary_plane_setplane().
> >
> > v2: take Ville's comments:
> > - get the right arguments for update_plane()
> > - use drm_crtc_get_hv_timing()
> >
> > Signed-off-by: Gustavo Padovan
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 89
> >
> > 1 file changed, 18 insertions(+), 71 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 9dd4952..f7c2e5f 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2857,74 +2857,6 @@ static void intel_update_pipe_size(struct intel_crtc
> > *crtc)
> > crtc->config.pipe_src_h = adjusted_mode->crtc_vdisplay;
> > }
> >
> > -static int
> > -intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
> > - struct drm_framebuffer *fb)
> > -{
> > - struct drm_device *dev = crtc->dev;
> > - struct drm_i915_private *dev_priv = dev->dev_private;
> > - struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > - enum pipe pipe = intel_crtc->pipe;
> > - struct drm_framebuffer *old_fb = crtc->primary->fb;
> > - struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> > - struct drm_i915_gem_object *old_obj = intel_fb_obj(old_fb);
> > - int ret;
> > -
> > - if (intel_crtc_has_pending_flip(crtc)) {
> > - DRM_ERROR("pipe is still busy with an old pageflip\n");
> > - return -EBUSY;
> > - }
> > -
> > - /* no fb bound */
> > - if (!fb) {
> > - DRM_ERROR("No FB bound\n");
> > - return 0;
> > - }
> > -
> > - if (intel_crtc->plane > INTEL_INFO(dev)->num_pipes) {
> > - DRM_ERROR("no plane for crtc: plane %c, num_pipes %d\n",
> > - plane_name(intel_crtc->plane),
> > - INTEL_INFO(dev)->num_pipes);
> > - return -EINVAL;
> > - }
> > -
> > - mutex_lock(&dev->struct_mutex);
> > - ret = intel_pin_and_fence_fb_obj(dev, obj, NULL);
> > - if (ret == 0)
> > - i915_gem_track_fb(old_obj, obj,
> > - INTEL_FRONTBUFFER_PRIMARY(pipe));
> > - mutex_unlock(&dev->struct_mutex);
> > - if (ret != 0) {
> > - DRM_ERROR("pin & fence failed\n");
> > - return ret;
> > - }
> > -
> > - intel_update_pipe_size(intel_crtc);
> > -
> > - dev_priv->display.update_primary_plane(crtc, fb, x, y);
> > -
> > - if (intel_crtc->active)
> > - intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_PRIMARY(pipe));
> > -
> > - crtc->primary->fb = fb;
> > - crtc->x = x;
> > - crtc->y = y;
> > -
> > - if (old_fb) {
> > - if (intel_crtc->active && old_fb != fb)
> > - intel_wait_for_vblank(dev, intel_crtc->pipe);
> > - mutex_lock(&dev->struct_mutex);
> > - intel_unpin_fb_obj(old_obj);
> > - mutex_unlock(&dev->struct_mutex);
> > - }
> > -
> > - mutex_lock(&dev->struct_mutex);
> > - intel_update_fbc(dev);
> > - mutex_unlock(&dev->struct_mutex);
> > -
> > - return 0;
> > -}
> > -
> > static void intel_fdi_normal_train(struct drm_crtc *crtc)
> > {
> > struct drm_device *dev = crtc->dev;
> > @@ -9681,6 +9613,8 @@ static int intel_crtc_commit_page_flip(struct
> > drm_crtc *crtc,
> > struct drm_framebuffer *old_fb = crtc->primary->fb;
> > struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> > struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > + struct drm_plane *primary = crtc->primary;
> > + struct intel_plane *intel_plane = to_intel_plane(primary);
> > enum pipe pipe = intel_crtc->pipe;
> > struct intel_unpin_work *work;
> > struct intel_engine_cs *ring;
> > @@ -9822,7 +9756,15 @@ free_work:
> > if (ret == -EIO) {
> > out_hang:
> > intel_crtc_wait_for_pending_flips(crtc);
> > - ret = intel_pipe_set_base(crtc, crtc->x, crtc->y, fb);
> > + ret = primary->funcs->update_plane(primary, crtc, fb,
> > + intel_plane->crtc_x,
> > + intel_plane->crtc_y,
> > + intel_plane->crtc_h,
> > + intel_plane->crtc_w,
> > + intel_plane->src_x,
> > + intel_plane->src_y,
> > + intel_plane->src_h,
> > + intel_plane->src_w);
> > if (ret == 0 && event) {
> > spin_lock_irq(&dev->event_lock);
> > drm_send_vblank_event(dev, pipe, event);
> > @@ -
[PATCH] regulator: stub out devm_regulator_get_exclusive
If we don't stup that call out, we will have
build failures for any drivers using that function
when .config happens to have CONFIG_REGULATOR=n.
One such case below, found with randconfig
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c: In function ?mdp4_kms_init?:
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:2: error: implicit declaration \
of function ?devm_regulator_get_exclusive?
[-Werror=implicit-function-declaration]
mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd");
^
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:16: error: assignment makes \
pointer from integer without a cast [-Werror]
mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd");
^
Signed-off-by: Felipe Balbi
---
include/linux/regulator/consumer.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/regulator/consumer.h
b/include/linux/regulator/consumer.h
index d347c80..ff61f3b 100644
--- a/include/linux/regulator/consumer.h
+++ b/include/linux/regulator/consumer.h
@@ -291,6 +291,11 @@ regulator_get_optional(struct device *dev, const char *id)
return ERR_PTR(-ENODEV);
}
+static inline struct regulator *__must_check
+devm_regulator_get_exclusive(struct device *dev, const char *id)
+{
+ return ERR_PTR(-ENODEV);
+}
static inline struct regulator *__must_check
devm_regulator_get_optional(struct device *dev, const char *id)
--
2.1.0.GIT
[PATCH] regulator: stub out devm_regulator_get_exclusive
Hi, On Fri, Oct 24, 2014 at 09:11:38PM +0100, Mark Brown wrote: > On Fri, Oct 24, 2014 at 02:15:11PM -0500, Felipe Balbi wrote: > > If we don't stup that call out, we will have > > build failures for any drivers using that function > > when .config happens to have CONFIG_REGULATOR=n. > > > > One such case below, found with randconfig > > > > drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c: In function ?mdp4_kms_init?: > > drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:2: error: implicit declaration \ > > As previously and repeatedly reported the regulator usage in this driver > appears extremely problematic, among these problems is that it almost > certainly has no sensible reason to be using regulator_get_exclusive() > or any variant of it. Sadly every time it's been raised with the video > people they've completely ignored the mail so here we are. > > Right now not having the stub seems to only be affecting buggy users > (which given the use cases for _exclusive() isn't *that* surprising) so > I'm more inclined to leave this there in the hope that the users get > fixed or we can at least get some sort of dialogue with the relevant > maintainers. quite frankly, flawed or not, I still think it's wrong of regulator framework to cause a build break during randconfig. Pretty much every other call is stubbed out, why wouldn't this be ? Moreover, if nobody cared to this day, why would this randconfig build break change their minds ? Not that I really care, it's just yet another build break I need to ignore when build-testing. Whatever. -- balbi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141024/83d352f7/attachment-0001.sig>
[GIT PULL] Armada DRM fixes
David, Please incorporate the latest Armada DRM fixes, which can be found at: git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-armada-fixes with SHA1 178e561f514fca4863c06a4af3501172e5627eb1. Three changes for the Armada DRM driver: 1. Add back the flags which tell the DRM core that we can do vblank. This was removed in error during the recent restructuring, and came to light while trying textured Xv rendering. 2. Fixing a refcount leak with Xv overlay. 3. As per recent discussion, the drm_vblank_pre_modeset() calls can cause deadlock with other changes to generic code. This change prevents those deadlocks by switching to the drm_crtc_vblank_*() calls instead. This will update the following files: drivers/gpu/drm/armada/armada_crtc.c | 21 ++--- drivers/gpu/drm/armada/armada_drv.c | 3 ++- 2 files changed, 12 insertions(+), 12 deletions(-) through these changes: Russell King (3): drm/armada: add IRQ support back drm/armada: fix page_flip refcounting leak drm/armada: convert to use vblank_on/off calls Many thanks.
[PATCH] regulator: stub out devm_regulator_get_exclusive
On Fri, Oct 24, 2014 at 02:15:11PM -0500, Felipe Balbi wrote: > If we don't stup that call out, we will have > build failures for any drivers using that function > when .config happens to have CONFIG_REGULATOR=n. > > One such case below, found with randconfig > > drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c: In function ?mdp4_kms_init?: > drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:2: error: implicit declaration \ > of function ?devm_regulator_get_exclusive? > [-Werror=implicit-function-declaration] > mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd"); > ^ > drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:16: error: assignment makes \ > pointer from integer without a cast [-Werror] > mdp4_kms->vdd = devm_regulator_get_exclusive(&pdev->dev, "vdd"); > ^ > Signed-off-by: Felipe Balbi randconfig attached. -- balbi -- next part -- # # Automatically generated file; DO NOT EDIT. # Linux/arm 3.18.0-rc1 Kernel Configuration # CONFIG_ARM=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_MIGHT_HAVE_PCI=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_VECTORS_BASE=0x CONFIG_ARM_PATCH_PHYS_VIRT=y CONFIG_GENERIC_BUG=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE="" CONFIG_COMPILE_TEST=y CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" # CONFIG_SWAP is not set # CONFIG_SYSVIPC is not set CONFIG_POSIX_MQUEUE=y CONFIG_CROSS_MEMORY_ATTACH=y CONFIG_FHANDLE=y # CONFIG_USELIB is not set # CONFIG_AUDIT is not set # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_HARDIRQS_SW_RESEND=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_HANDLE_DOMAIN_IRQ=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ_COMMON=y # CONFIG_HZ_PERIODIC is not set CONFIG_NO_HZ_IDLE=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y # # CPU/Task time and stats accounting # CONFIG_TICK_CPU_ACCOUNTING=y # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set # CONFIG_IRQ_TIME_ACCOUNTING is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y # CONFIG_TASKSTATS is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set CONFIG_TASKS_RCU=y CONFIG_RCU_STALL_COMMON=y # CONFIG_TREE_RCU_TRACE is not set # CONFIG_BUILD_BIN2C is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_GENERIC_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y CONFIG_PROC_PID_CPUSET=y # CONFIG_CGROUP_CPUACCT is not set CONFIG_RESOURCE_COUNTERS=y # CONFIG_MEMCG is not set CONFIG_CGROUP_PERF=y # CONFIG_CGROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_NET_NS=y # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_RELAY=y # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_ANON_INODES=y CONFIG_HAVE_UID16=y CONFIG_EXPERT=y CONFIG_UID16=y CONFIG_SGETMASK_SYSCALL=y # CONFIG_SYSFS_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_BASE_FULL=y # CONFIG_FUTEX is not set CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_ADVISE_SYSCALLS=y # CONFIG_PCI_QUIRKS is not set CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # CONFIG_DEBUG_PERF_USE_VMALLOC is not set # CONFIG_VM_EVENT_COUNTERS is not set CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_SYSTEM_TRUSTED_KEYRING is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y # CONFIG_OPROFILE is not set CONFIG_HAVE_OPROFILE=y CONFIG_JUMP_LABEL=y CONFIG_UPROBES=y # CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_ARCH_USE_BUILTIN_BSWAP=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_HAVE_DMA_CONTIGUOUS=y CONFIG_G
[PATCH] regulator: stub out devm_regulator_get_exclusive
On Fri, Oct 24, 2014 at 02:15:11PM -0500, Felipe Balbi wrote: > If we don't stup that call out, we will have > build failures for any drivers using that function > when .config happens to have CONFIG_REGULATOR=n. > > One such case below, found with randconfig > > drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c: In function ?mdp4_kms_init?: > drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c:384:2: error: implicit declaration \ As previously and repeatedly reported the regulator usage in this driver appears extremely problematic, among these problems is that it almost certainly has no sensible reason to be using regulator_get_exclusive() or any variant of it. Sadly every time it's been raised with the video people they've completely ignored the mail so here we are. Right now not having the stub seems to only be affecting buggy users (which given the use cases for _exclusive() isn't *that* surprising) so I'm more inclined to leave this there in the hope that the users get fixed or we can at least get some sort of dialogue with the relevant maintainers. -- 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/20141024/9ce9a9ea/attachment-0001.sig>
[PATCH] regulator: stub out devm_regulator_get_exclusive
On Fri, Oct 24, 2014 at 03:18:27PM -0500, Felipe Balbi wrote: > On Fri, Oct 24, 2014 at 09:11:38PM +0100, Mark Brown wrote: > > Right now not having the stub seems to only be affecting buggy users > > (which given the use cases for _exclusive() isn't *that* surprising) so > > I'm more inclined to leave this there in the hope that the users get > > fixed or we can at least get some sort of dialogue with the relevant > > maintainers. > quite frankly, flawed or not, I still think it's wrong of regulator > framework to cause a build break during randconfig. Pretty much every > other call is stubbed out, why wouldn't this be ? Moreover, if nobody Well, it wasn't precisely a thought through choice before it happened but when it was reported it wasn't obvious how someone could use a stub (or what that stub should be) so I looked at the code and it just didn't look at all sensible which made me think having the stub was a bad idea. There are some bits of the regulator API which can quite happily be stubbed out since the stub behaviour is within what could happen in normal usage but there are other bits where the user really has to care about what's happening and should probably depend on the regulator API, this is one of the latter bits. > cared to this day, why would this randconfig build break change their > minds ? For me it's more that I'm not terribly motivated to add code which only serves to enable broken usage; it may be that there's a perfectly good explanation for what the driver is doing but nobody seems to care about it so... -- 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/20141024/b562/attachment.sig>
[PATCH] regulator: stub out devm_regulator_get_exclusive
On Fri, Oct 24, 2014 at 04:36:24PM -0400, Rob Clark wrote: > iirc, I was using _get_exclusive() in a few places where I wanted to > be sure not to get dummy-regulator in cases where I should > -EPROBE_DEFER instead (since probe order with DT is slightly > hilarious, and since I depend on a few other drivers I end up > deferring at least a couple times at boot)... I don't quite remember > the details. But afaict regulator_get() still allows dummy-regulator, > which is what I specifically don't want. No, this is actually making things worse. You will only get a dummy regulator from regulator_get() if no regulator at all is mapped in the DT, if one is mapped then you'll always get either an -EPROBE_DEFER or the real regulator. Right now the driver is broken with respect to -EPROBE_DEFER since it just completely ignores the error code and carries on happily if any error is returned which means that the behaviour is going to be unstable on any given system, what happens will depend on probe order which could in turn depend on what's been built modular and so on. As far as I can tell the only thing the driver does with the regulator it's grabbing exclusively is enable it in probe() and that's going to work just as well with the dummy regulator anyway so I can't see any reason to worry if the driver is getting one. > If you have a recommendation for a better way, I am all ears. Just use regulator_get() (or better, devm_regulator_get()) and pay attention to the errors. The driver should also disable the regulator on remove and I'd be surprised if the other two regulators shouldn't be using a normal _get() too. If there is a good reason to use _optional() then the code should be changed to use ERR_PTR() rather than NULL to check for missing regulators and the driver needs to keep them enabled as long as it's using them. Given that the two optional regulators are only set to one specific value it's a bit surprising that the DT doesn't do this but I guess it's possible there could be broken DTs out there that do give permission for set_voltage() for a range rather than specifying the correct voltage. -- 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/20141024/21a3ecd6/attachment.sig>
