[PATCH] drm: radeon: *_cs_packet_parse_vline() cleanup
Simplify the way the return value is set a number of times (mostly on
error).
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Should a patch like this go through the trivial tree?
Documentation/SubmittingPatches wasn't entirely clear on that.
drivers/gpu/drm/radeon/evergreen_cs.c | 24
drivers/gpu/drm/radeon/r100.c | 16 ++--
drivers/gpu/drm/radeon/r600_cs.c | 25 +
3 files changed, 23 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen_cs.c
b/drivers/gpu/drm/radeon/evergreen_cs.c
index 345a75a..d091e70 100644
--- a/drivers/gpu/drm/radeon/evergreen_cs.c
+++ b/drivers/gpu/drm/radeon/evergreen_cs.c
@@ -292,33 +292,28 @@ static int evergreen_cs_packet_parse_vline(struct
radeon_cs_parser *p)
if (wait_reg_mem.type != PACKET_TYPE3 ||
wait_reg_mem.opcode != PACKET3_WAIT_REG_MEM) {
DRM_ERROR(vline wait missing WAIT_REG_MEM segment\n);
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
wait_reg_mem_info = radeon_get_ib_value(p, wait_reg_mem.idx + 1);
/* bit 4 is reg (0) or mem (1) */
if (wait_reg_mem_info 0x10) {
DRM_ERROR(vline WAIT_REG_MEM waiting on MEM rather than
REG\n);
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
/* waiting for value to be equal */
if ((wait_reg_mem_info 0x7) != 0x3) {
DRM_ERROR(vline WAIT_REG_MEM function not equal\n);
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
if ((radeon_get_ib_value(p, wait_reg_mem.idx + 2) 2) !=
EVERGREEN_VLINE_STATUS) {
DRM_ERROR(vline WAIT_REG_MEM bad reg\n);
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
if (radeon_get_ib_value(p, wait_reg_mem.idx + 5) !=
EVERGREEN_VLINE_STAT) {
DRM_ERROR(vline WAIT_REG_MEM bad bit mask\n);
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
/* jump over the NOP */
@@ -336,8 +331,7 @@ static int evergreen_cs_packet_parse_vline(struct
radeon_cs_parser *p)
obj = drm_mode_object_find(p-rdev-ddev, crtc_id,
DRM_MODE_OBJECT_CRTC);
if (!obj) {
DRM_ERROR(cannot find crtc %d\n, crtc_id);
- r = -EINVAL;
- goto out;
+ return -EINVAL;
}
crtc = obj_to_crtc(obj);
radeon_crtc = to_radeon_crtc(crtc);
@@ -362,12 +356,10 @@ static int evergreen_cs_packet_parse_vline(struct
radeon_cs_parser *p)
break;
default:
DRM_ERROR(unknown crtc reloc\n);
- r = -EINVAL;
- goto out;
+ return -EINVAL;
}
}
-out:
- return r;
+ return 0;
}
static int evergreen_packet0_check(struct radeon_cs_parser *p,
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index e372f9e..fcc23e4 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1205,14 +1205,12 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser
*p)
if (waitreloc.reg != RADEON_WAIT_UNTIL ||
waitreloc.count != 0) {
DRM_ERROR(vline wait had illegal wait until segment\n);
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
if (radeon_get_ib_value(p, waitreloc.idx + 1) !=
RADEON_WAIT_CRTC_VLINE) {
DRM_ERROR(vline wait had illegal wait until\n);
- r = -EINVAL;
- return r;
+ return -EINVAL;
}
/* jump over the NOP */
@@ -1230,8 +1228,7 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser *p)
obj = drm_mode_object_find(p-rdev-ddev, crtc_id,
DRM_MODE_OBJECT_CRTC);
if (!obj) {
DRM_ERROR(cannot find crtc %d\n, crtc_id);
- r = -EINVAL;
- goto out;
+ return -EINVAL;
}
crtc = obj_to_crtc(obj);
radeon_crtc = to_radeon_crtc(crtc);
@@ -1253,14 +1250,13 @@ int r100_cs_packet_parse_vline(struct radeon_cs_parser
*p)
break;
default:
DRM_ERROR(unknown crtc reloc\n);
- r = -EINVAL;
- goto out;
+ return -EINVAL;
}
ib[h_idx] = header;
ib[h_idx + 3] |= RADEON_ENG_DISPLAY_SELECT_CRTC1;
}
-out:
- return r;
+
+ return 0;
}
/**
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 153095f..5bfed09 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -687,33 +687,28
i915: kernel errors at resume
0) On a laptop I use I've ran into i915 kernel errors at resume. I see these only every now and then: not on all resumes. The pattern of these errors (and preceding messages) is basically always like this: 6[14673.762529] [drm] Changing LVDS panel from (+hsync, +vsync) to (-hsync, -vsync) 6[14673.824599] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state 3[14673.825071] render error detected, EIR: 0x0010 3[14673.825071] page table error 3[14673.825071] PGTBL_ER: 0x0100 3[14673.825071] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, masking 1) I've only noticed this because: - I tend to check for KERN_ERR messages in the logs; and - the errors (ie, the messages with a 3 prefix) look scary when text mode briefly flashes by at suspend and at resume. Otherwise the display on this machine seems to work just fine. 2) The logs on this machine only have information for v3.3 based kernels. I haven't checked whether earlier kernels also do this. Nor have I checked whether this is fixed in the current v3.4 release candidates. 3) Some similar reports, but for messages printed at boot: http://lists.freedesktop.org/archives/dri-devel/2011-January/007302.html http://lists.freedesktop.org/archives/dri-devel/2012-January/018158.html 4) What can I do to (help) make these messages go away? Paul Bolle ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915: kernel errors at resume
On Thu, 2012-04-19 at 11:04 +0200, Paul Bolle wrote: 6[14673.824599] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state I triggered this issue once again in the session I run currently: $ cat /sys/kernel/debug/dri/0/i915_error_state | wc -c 689681 What part of that almost 700K file could be of interest? Paul Bolle ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915: kernel errors at resume
On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote: On Sat, Apr 21, 2012 at 02:25:55PM +0200, Paul Bolle wrote: What part of that almost 700K file could be of interest? All of it. Please file a bug report with the error state attach (the entire thing), complete dmesg showing when the problem happens and a short description of the issue at bugs.freedesktop.org against DRI, component DRM/Intel. OK, I'll do that then. Would you know whether bugs.freedesktop.org requires me to compress files of that size? Paul Bollw ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: i915: kernel errors at resume
On Sat, 2012-04-21 at 14:54 +0200, Daniel Vetter wrote: Please file a bug report with the error state attach (the entire thing), complete dmesg showing when the problem happens and a short description of the issue at bugs.freedesktop.org against DRI, component DRM/Intel. See https://bugs.freedesktop.org/show_bug.cgi?id=49041 for that report. Paul Bolle ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nv40/pm: silence GCC warnings
Building nv40_pm.o triggers these GCC warnings: drivers/gpu/drm/nouveau/nv40_pm.c: In function 'nv40_pm_clocks_pre': drivers/gpu/drm/nouveau/nv40_pm.c:164:41: warning: 'log2P' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/gpu/drm/nouveau/nv40_pm.c:165:38: warning: 'M2' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/gpu/drm/nouveau/nv40_pm.c:165:45: warning: 'M1' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/gpu/drm/nouveau/nv40_pm.c:165:25: warning: 'N2' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/gpu/drm/nouveau/nv40_pm.c:165:51: warning: 'N1' may be used uninitialized in this function [-Wmaybe-uninitialized] But these variables seem to be initialized when used there. If the preceding call of nv40_calc_pll() fails it will return a negative value and this code will never be run. And if that call succeeds it will return zero and all those five variables ought to be initialized when used there. Anyhow, it turns out that these warnings can be silenced by giving GCC slightly more detailed information a little earlier. See, get_pll_limits() returns an error-code integer (ie, negative on failure, zero on success). And a trivial tweak to nv40_calc_pll() that takes this into account makes these errors go away. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- 0) I noticed these warnings while building recent releases (eg, v3.6-rc7, v3.6, and v3.6.1) on current Fedora 17, using Fedora's default config. But I found identical warnings in a build log for release v3.4-rc1. I didn't bother checking earlier releases. 1) Compile tested only (I do not have the hardware involved at hand). 2) This is not the only place where get_pll_limits()'s return value is checked. But this is apparently the only place where GCC needs to know that any non-zero return will be negative. drivers/gpu/drm/nouveau/nv40_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c b/drivers/gpu/drm/nouveau/nv40_pm.c index e66273a..3df30cb 100644 --- a/drivers/gpu/drm/nouveau/nv40_pm.c +++ b/drivers/gpu/drm/nouveau/nv40_pm.c @@ -114,7 +114,7 @@ nv40_calc_pll(struct drm_device *dev, u32 reg, struct pll_lims *pll, int ret; ret = get_pll_limits(dev, reg, pll); - if (ret) + if (ret 0) return ret; if (clk pll-vco1.maxfreq) -- 1.7.11.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] radeon: add AGPMode 1 quirk for RV250
The Intel 82855PM host bridge / Mobility FireGL 9000 RV250 combination
in an (outdated) ThinkPad T41 needs AGPMode 1 for suspend/resume (under
KMS, that is). So add a quirk for it.
(Change R250 to RV250 in comment for preceding quirk too.)
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
0) Last tested on v3.6.7. The patch was cherry-picked on top of
v3.7-rc6.
1) A similar patch was submitted twenty months ago via
https://bugzilla.redhat.com/show_bug.cgi?id=531825 , but nothing
happened after that.
drivers/gpu/drm/radeon/radeon_agp.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_agp.c
b/drivers/gpu/drm/radeon/radeon_agp.c
index 10ea17a..4243334 100644
--- a/drivers/gpu/drm/radeon/radeon_agp.c
+++ b/drivers/gpu/drm/radeon/radeon_agp.c
@@ -69,9 +69,12 @@ static struct radeon_agpmode_quirk
radeon_agpmode_quirk_list[] = {
/* Intel 82830 830 Chipset Host Bridge / Mobility M6 LY Needs AGPMode 2
(fdo #17360)*/
{ PCI_VENDOR_ID_INTEL, 0x3575, PCI_VENDOR_ID_ATI, 0x4c59,
PCI_VENDOR_ID_DELL, 0x00e3, 2},
- /* Intel 82852/82855 host bridge / Mobility FireGL 9000 R250 Needs
AGPMode 1 (lp #296617) */
+ /* Intel 82852/82855 host bridge / Mobility FireGL 9000 RV250 Needs
AGPMode 1 (lp #296617) */
{ PCI_VENDOR_ID_INTEL, 0x3580, PCI_VENDOR_ID_ATI, 0x4c66,
PCI_VENDOR_ID_DELL, 0x0149, 1},
+ /* Intel 82855PM host bridge / Mobility FireGL 9000 RV250 Needs AGPMode
1 for suspend/resume */
+ { PCI_VENDOR_ID_INTEL, 0x3340, PCI_VENDOR_ID_ATI, 0x4c66,
+ PCI_VENDOR_ID_IBM, 0x0531, 1},
/* Intel 82852/82855 host bridge / Mobility 9600 M10 RV350 Needs
AGPMode 1 (deb #467460) */
{ PCI_VENDOR_ID_INTEL, 0x3580, PCI_VENDOR_ID_ATI, 0x4e50,
0x1025, 0x0061, 1},
--
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [RFC] drm/radeon: return 0 on successful gpu reset
On an (outdated) laptop the radeon driver (almost always) prints, during
the first resume of each session:
[drm] crtc 1 is connected to a TV
This message is a bit puzzling as, as far as I know, no TV has ever
been connected to this laptop. Anyhow, before v3.5, if that happened the
radeon driver then printed an error during all following resumes:
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
(-35 is -EDEADLK.) But the resume would succeed and the driver seemed to
run without too much trouble. From v3.5 onwards things changed. If the
(puzzling) message about crtc 1 was printed on first resume the laptop
would simply hang on second resume. Only a manual power off would then
be possible. In that case nothing of interest would be found in the
(truncated) logs. And, most annoyingly, the hang would never happen if
the laptop was booted with, say, console=ttyS0,115200n8 added to the
kernel command line.
I bisected the hang to commit 6c6f478370eccfbfafbdc6fc55c0def03e58f124
(drm/radeon: rework recursive gpu reset handling), which was added in
the v3.5 release cycle. After discovering that and poking at the driver
it turned out that this hang is triggered by radeon_cs_handle_lockup()
returning -EAGAIN after successfully resetting the gpu. Simply returning
0 makes the hang disappear (and makes the drm error reappear).
Nothing in the code or the commit explanation clarifies why -EAGAIN
should be returned on successful gpu reset. So I suggest
radeon_cs_handle_lockup() simply returns what radeon_gpu_reset()
returns, eg 0 (on success) or a negative error code (on failure).
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
0) This exact patch is untested (but I run something comparable).
1) Sent as an RFC because I do not understand why this laptop (almost
always) prints the crtc 1 message on first resume. Note that another
workaround for this hang is simply booting with radeon.tv=0.
2) Also sent as an RFC because I have no idea whatsoever why returning
-EAGAIN will hang the machine. I guess it's returned to userland by
radeon_cs_ioctl(). What code uses that ioctl? And what does that code do
on -EAGAIN that hangs this laptop?
3) A third reason to send this as an RFC is that I also have no idea why
this hang doesn't happen when booting with console=ttyS0,115200n8 or
even console=tty0! But I guess I'm now allowed to call this hang a
Heisenbug.
drivers/gpu/drm/radeon/radeon_cs.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 41672cc..a302c00 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -486,11 +486,8 @@ out:
static int radeon_cs_handle_lockup(struct radeon_device *rdev, int r)
{
- if (r == -EDEADLK) {
+ if (r == -EDEADLK)
r = radeon_gpu_reset(rdev);
- if (!r)
- r = -EAGAIN;
- }
return r;
}
--
1.7.7.6
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC] drm/radeon: return 0 on successful gpu reset
On Tue, 2012-12-18 at 10:22 -0500, Alex Deucher wrote: On Tue, Dec 18, 2012 at 5:36 AM, Christian König deathsim...@vodafone.de wrote: On 17.12.2012 22:31, Paul Bolle wrote: 1) Sent as an RFC because I do not understand why this laptop (almost always) prints the crtc 1 message on first resume. Note that another workaround for this hang is simply booting with radeon.tv=0. Alex should probably take a look into this, since he probably is the one with the deepest knowledge of the display engine. My best guess is that it is just some error while probing for an attached TV and actually isn't so bad after all. TV detection is always a bit flakey. I suspect some register or gpio related to TV out doesn't get restored properly on resume which results in a false positive. What asic is this? It's an RV250, which makes the asic r200, doesn't it? You should definitely try Alex latest drm-fixes-3.8 branch (git://people.freedesktop.org/~agd5f/linux) since the possibility is quite high that we already have fixed that bug. If that doesn't helps then please open a bug report and leave me a note so that I can investigate further. I don't have a 3.8 fixes branch up just yet, but will soon. I see. I'll watch that repository, but I would appreciate it if you notify me if that branch pops up. Paul Bolle ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC] drm/radeon: return 0 on successful gpu reset
On Thu, 2012-12-20 at 13:37 -0500, Alex Deucher wrote: On Tue, Dec 18, 2012 at 12:28 PM, Paul Bolle pebo...@tiscali.nl wrote: On Tue, 2012-12-18 at 10:22 -0500, Alex Deucher wrote: On Tue, Dec 18, 2012 at 5:36 AM, Christian König deathsim...@vodafone.de wrote: You should definitely try Alex latest drm-fixes-3.8 branch (git://people.freedesktop.org/~agd5f/linux) since the possibility is quite high that we already have fixed that bug. If that doesn't helps then please open a bug report and leave me a note so that I can investigate further. I don't have a 3.8 fixes branch up just yet, but will soon. I see. I'll watch that repository, but I would appreciate it if you notify me if that branch pops up. http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.8 Thanks. I tried drm-fixes-3.8, at commit 4613ca14b9739428abb53bef9cd0f8b3fee23a95 (drm/radeon: add support for MEM_WRITE packet), on top of v3.7. It hangs in the exact same way. Christian, were should I open a bug, and under which component, etc.? Paul Bolle ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tegra: drop select DRM_HDMI
Commit ac24c2204a76e5b42aa103bf963ae0eda1b827f3 (drm/tegra: Use generic HDMI infoframe helpers) added select DRM_HDMI to the DRM_TEGRA Kconfig entry. But there is no Kconfig symbol named DRM_HDMI. The select statement for that symbol is a nop. Drop it. What was needed to use HDMI functionality was to select HDMI (which this entry already did through depending on DRM) and to include linux/hdmi.h (which this commit also did). Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Untested. drivers/gpu/drm/tegra/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig index c92955d..be1daf7 100644 --- a/drivers/gpu/drm/tegra/Kconfig +++ b/drivers/gpu/drm/tegra/Kconfig @@ -4,7 +4,6 @@ config DRM_TEGRA select DRM_KMS_HELPER select DRM_GEM_CMA_HELPER select DRM_KMS_CMA_HELPER - select DRM_HDMI select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT -- 1.7.11.7 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/omap: change !CONFIG_FB_OMAP2 to !FB_OMAP2
Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Untested. Perhaps the first test that people with access to the relevant hardware might do, is to test _before applying this patch_ with FB_OMAP2 set. Perhaps this negative dependency isn't needed at all. Or is it obvious? drivers/gpu/drm/omapdrm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig index 09f65dc..45875a0 100644 --- a/drivers/gpu/drm/omapdrm/Kconfig +++ b/drivers/gpu/drm/omapdrm/Kconfig @@ -1,7 +1,7 @@ config DRM_OMAP tristate OMAP DRM - depends on DRM !CONFIG_FB_OMAP2 + depends on DRM !FB_OMAP2 depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM depends on OMAP2_DSS select DRM_KMS_HELPER -- 1.7.11.7 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/omap: change !CONFIG_FB_OMAP2 to !FB_OMAP2
On Wed, 2013-03-13 at 20:48 +0100, Paul Bolle wrote: Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Untested. Perhaps the first test that people with access to the relevant hardware might do, is to test _before applying this patch_ with FB_OMAP2 set. Perhaps this negative dependency isn't needed at all. Or is it obvious? drivers/gpu/drm/omapdrm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) This patch was sent exactly three months ago, shortly after v3.9-rc2 was released. This obvious typo is still present in v3.10-rc5. I didn't received any feedback on this patch. Did anyone had a look at it? Is it perhaps queued somewhere? Paul Bolle diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig index 09f65dc..45875a0 100644 --- a/drivers/gpu/drm/omapdrm/Kconfig +++ b/drivers/gpu/drm/omapdrm/Kconfig @@ -1,7 +1,7 @@ config DRM_OMAP tristate OMAP DRM - depends on DRM !CONFIG_FB_OMAP2 + depends on DRM !FB_OMAP2 depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM depends on OMAP2_DSS select DRM_KMS_HELPER ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/tegra: Include linux/types.h
make headers_check complains about include/uapi/drm/tegra_drm.h:
[...]/usr/include/drm/tegra_drm.h:21: found __[us]{8,16,32,64} type without
#include linux/types.h
So let's include linux/types.h in this header.
Signed-off-by: Paul Bolle pebo...@tiscali.nl
---
Tested only with make headers_check. I don't actually build or run
code that uses tegra_drm.h.
include/uapi/drm/tegra_drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index 6e132a2..6698e81 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -17,6 +17,8 @@
#ifndef _UAPI_TEGRA_DRM_H_
#define _UAPI_TEGRA_DRM_H_
+#include linux/types.h
+
struct drm_tegra_gem_create {
__u64 size;
__u32 flags;
--
1.8.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tegra: Include linux/types.h
On Mon, 2013-06-17 at 22:33 +0200, Thierry Reding wrote: That has already been fixed in linux-next. This header was added in v3.10-rc1. The fix in linux-next will ship in v3.11. Isn't that fix appropriate for (one of) the upcoming v3.10 release candidate(s)? Thanks, Paul Bolle ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
[Detailed post, but please give it a quick scan.]
On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote:
> On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
> > Bisecting the offending commit between v4.8 and v4.8.1 would be a good
> > start.
>
> That would be between v4.7 and v4.8. (I guess my report was
> ambiguous.)
>
> That might take some time. Because bisecting always takes a long time
> and especially since hitting this WARNING sometimes takes over an hour.
> Anyhow, please prod me if I stay silent for too long.
0) So I've lost my courage to do a bisect when my first attempt landed
me in v4.6-rc3. This is about for issue popping up between v4.7 and
v4.8-rc1.
1) So I used the most reliable debugging tool that I actually
understand: printk():
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fbcfed63a76e..791de414cf1e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14771,10 +14771,16 @@ skl_max_scale(struct intel_crtc *intel_crtc, struct
intel_crtc_state *crtc_state
return DRM_PLANE_HELPER_NO_SCALING;
crtc_clock = crtc_state->base.adjusted_mode.crtc_clock;
- cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
+ if (WARN_ON_ONCE(!crtc_clock))
+ return DRM_PLANE_HELPER_NO_SCALING;
- if (WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock))
+ cdclk = to_intel_atomic_state(crtc_state->base.state)->cdclk;
+ if (WARN_ON_ONCE(cdclk < crtc_clock)) {
+ printk(KERN_DEBUG "i915: cdclk < crtc_clock: %d < %d\n", cdclk,
crtc_clock);
return DRM_PLANE_HELPER_NO_SCALING;
+ }
+
+ printk_ratelimited(KERN_DEBUG "i915: cdclk >= crtc_clock: %d >= %d\n",
cdclk, crtc_clock);
/*
* skl max scale is lower of:
2) This taught me that crtc_clock always is 373250 on my machine. cdclk
mostly is 45, but every now and then it briefly is 337500.
3) Now the interesting pattern is that cdclk drops to 337500 only after
two quick calls of skl_max_scale() with cdclk set to 45, and a
roughly 300ms pause before the third call of that function. Example:
<7>[23758.501933] i915: cdclk >= crtc_clock: 45 >= 373250
<7>[23758.515211] i915: cdclk >= crtc_clock: 45 >= 373250
<7>[23758.869057] i915: cdclk < crtc_clock: 337500 < 373250
This pattern of cdclk being 337500 after roughly 300ms is surprisingly
stable.
4) So _perhaps_ there's some roughly 300ms timeout, somehow, somewhere,
that sets cdclk to 337500 and triggers this issue. Ideas?
To be continued,
Paul Bolle
drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
On a laptop that tracks the latest stable release (Ie, it now runs v4.8.1) I see this WARNING Â Â Â WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock) Full trace pasted below. I never saw this WARNING before v4.8. Since v4.8 I've had it in all (four, actually) boots. What am I expected to do about this WARNING? Thanks, Paul Bolle WARNING: CPU: 3 PID: 1368 at drivers/gpu/drm/i915/intel_display.c:14178 skl_max_scale.part.120+0x75/0x80 [i915] WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock) Modules linked in: rfcomm fuse nf_conntrack_netbios_ns nf_conntrack_broadcast ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 cmac nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw iptable_security ebtable_filter ebtables ip6table_filter ip6_tables bnep vfat fat arc4 snd_hda_codec_hdmi snd_soc_skl dell_led snd_soc_skl_ipc snd_soc_sst_ipc snd_soc_sst_dsp snd_hda_ext_core snd_soc_sst_match snd_soc_core intel_rapl snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal coretemp kvm_intel snd_compress snd_pcm_dmaengine ac97_bus kvm snd_hda_intel iwlmvm snd_hda_codec mac80211 iTCO_wdt iTCO_vendor_support uvcvideo snd_hda_core snd_hwdep snd_seq irqbypass dell_laptop i2c_designware_platform i2c_designware_core dell_wmi crct10dif_pclmul dell_smbios dcdbas crc32_pclmul snd_seq_device iwlwifi videobuf2_vmalloc videobuf2_memops ghash_clmulni_intel snd_pcm videobuf2_v4l2 videobuf2_core cfg80211 videodev media joydev pcspkr mei_me rtsx_pci_ms memstick snd_timer i2c_i801 i2c_smbus mei snd btusb soundcore shpchp hci_uart btrtl btbcm btqca idma64 btintel bluetooth intel_pch_thermal processor_thermal_device intel_lpss_pci intel_soc_dts_iosf wmi pinctrl_sunrisepoint intel_lpss_acpi rfkill pinctrl_intel intel_lpss int3400_thermal acpi_als int3403_thermal int340x_thermal_zone kfifo_buf acpi_thermal_rel intel_hid industrialio sparse_keymap acpi_pad tpm_tis tpm_tis_core tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc hid_multitouch i915 rtsx_pci_sdmmc mmc_core i2c_algo_bit drm_kms_helper crc32c_intel drm serio_raw nvme rtsx_pci nvme_core i2c_hid video fjes CPU: 3 PID: 1368 Comm: Xorg Not tainted 4.8.1-1.local1.fc24.x86_64 #1 Hardware name: Dell Inc. XPS 13 9350/09JHRY, BIOS 1.4.4 06/14/2016 0286 df2f374c a31528d53910 b83e5cfd a31528d53960 a31528d53950 b80a7d5b 3762c72b3010 a3151e4d8cc0 a31526c23800 a31526e6 Call Trace: [] dump_stack+0x63/0x86 [] __warn+0xcb/0xf0 [] warn_slowpath_fmt+0x5f/0x80 [] ? sort+0x147/0x220 [] ? drm_atomic_helper_normalize_zpos+0x264/0x300 [drm_kms_helper] [] skl_max_scale.part.120+0x75/0x80 [i915] [] intel_check_primary_plane+0xc6/0xe0 [i915] [] ? drm_atomic_helper_normalize_zpos+0x264/0x300 [drm_kms_helper] [] intel_plane_atomic_check+0x132/0x1f0 [i915] [] drm_atomic_helper_check_planes+0x84/0x200 [drm_kms_helper] [] intel_atomic_check+0x9a7/0x11a0 [i915] [] ? __kmalloc_track_caller+0x17a/0x210 [] drm_atomic_check_only+0x187/0x610 [drm] [] ? drm_atomic_get_crtc_state+0x88/0x100 [drm] [] drm_atomic_commit+0x17/0x60 [drm] [] drm_atomic_helper_update_plane+0xec/0x130 [drm_kms_helper] [] __setplane_internal+0x22b/0x270 [drm] [] drm_mode_cursor_universal+0x139/0x240 [drm] [] drm_mode_cursor_common+0x7e/0x180 [drm] [] drm_mode_cursor2_ioctl+0xe/0x10 [drm] [] drm_ioctl+0x1da/0x4b0 [drm] [] ? drm_mode_cursor_ioctl+0x70/0x70 [drm] [] ? enqueue_hrtimer+0x3d/0x80 [] do_vfs_ioctl+0xa3/0x5e0 [] ? __sys_recvmsg+0x51/0x90 [] SyS_ioctl+0x79/0x90 [] entry_SYSCALL_64_fastpath+0x1a/0xa4
[Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote: > Bisecting the offending commit between v4.8 and v4.8.1 would be a good > start. That would be between v4.7 and v4.8. (I guess my report was ambiguous.) That might take some time. Because bisecting always takes a long time and especially since hitting this WARNING sometimes takes over an hour. Anyhow, please prod me if I stay silent for too long. Thanks, Paul Bolle
[Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
On Wed, 2016-10-12 at 17:34 +0300, Jani Nikula wrote: > In the mean time, please file a bug over at [1] so we don't lose > track. Done: Â https://bugs.freedesktop.org/show_bug.cgi?id=98214 Paul Bolle
[Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote: > That might take some time. Because bisecting always takes a long time > and especially since hitting this WARNING sometimes takes over an hour. > Anyhow, please prod me if I stay silent for too long. For the record: I just had to power cycle this laptop because it got into that lovely state where it just locks without accepting any input (no, I don't have netconsole enabled). Assuming this lockup is related: this could be more urgent than I thought. Paul Bolle
[Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)
[Adding Matt]
On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote:
> Bisecting the offending commit between v4.8 and v4.8.1 would be a good
> start.
0) Why use a personal notebook when one can just post any half baked
idea to lkml?
1) I stumbled on https://bugzilla.redhat.com/show_bug.cgi?id=1361357 (s
ame hardware, rather similar trace).
2) That report was about the first Fedora (rawhide) kernel release
after this commit http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/co
mmit/?h=f25=7d2c2f2d91793b5da452bee9bea4fa32051c8608Â ("Bring in
patch-series from drm-next to fix skl_update_other_pipe_wm issues").
3) That seventeen part series ended up in v4.8. The last commit of that
series is commit 5b483747a925 ("drm/i915: Remove wm_config from
dev_priv/intel_atomic_state").
4) So, with a little bit of luck, my bisect might only need to look at
those seventeen commits. Still, it will probably be next week before I
have a day or two to actually perform that bisect.
To be continued,
Paul Bolle
[RFC PATCH] get_maintainer: Look for arbitrary letter prefixes in sections
On Mon, 2016-10-24 at 11:05 -0700, Joe Perches wrote:
> Jani Nikula proposes patches to add a few new letter prefixes
> for "B:" bug reporting and "C:" maintainer chatting to the
> various sections of MAINTAINERS.
>
> Add a generic mechanism to get_maintainer.pl to find sections that
> have any combination of "[A-Z]" letter prefix types in a section.
>
> Signed-off-by: Joe Perches
This patch made it into linux-next (ie, next-20161028).
> --- a/scripts/get_maintainer.pl
> +++ b/scripts/get_maintainer.pl
> @@ -271,7 +273,8 @@ $output_multiline = 0 if ($output_separator ne ", ");
> Â $output_rolestats = 1 if ($interactive);
> Â $output_roles = 1 if ($output_rolestats);
> Â
> -if ($sections) {
> +if ($sections || $letters ne "") {
> +Â Â Â Â $sections = 1;
This triggers:
   Unrecognized character \xA0; marked by <-- HERE after <-- HERE near
column 1 at ./scripts/get_maintainer.pl line 277.
Git blame shows:
   git blame -L 277,+1 ./scripts/get_maintainer.pl
b67071653d3fc (Joe Perches 2016-10-28 13:22:01 +1100 277)
$sections = 1;
(A0 seems to be the no break space. That character was inserted more
often further down the patch.)
Anybody else seeing this?
Paul Bolle
[RFC PATCH] get_maintainer: Look for arbitrary letter prefixes in sections
On Thu, 2016-11-03 at 02:16 -0700, Joe Perches wrote: > Yes, it's been reported and should be fixed in -mm. > The fix should show up in -next in a little bit. Great. > For now, try: > $ sed -i -e 's/\xA0/ /g' scripts/get_maintainer.pl Thanks, Paul Bolle
[PATCH] drm/vmwgfx: use *_32_bits() macros
[Added Sinclair, Thomas, and "VMware Graphics".] On do, 2016-04-14 at 07:34 -0700, Joe Perches wrote: > On Thu, 2016-04-14 at 13:32 +0200, Paul Bolle wrote: > > On do, 2016-03-03 at 11:26 +0100, Paul Bolle wrote: > > > > > > Use the upper_32_bits() macro instead of the four line equivalent that > > > triggers a GCC warning on 32 bits x86: > > > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function > > > 'vmw_cmdbuf_header_submit': > > > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:297:25: warning: right > > > shift count >= width of type [-Wshift-count-overflow] > > >val = (header->handle >> 32); > > > ^ > > > > > > And use the lower_32_bits() macro instead of and-ing with a 32 bits > > > mask. > > > > > > Signed-off-by: Paul Bolle > > > --- > > > Note: compile tested only (I don't use any of vmware's products). > > The warning can still be seen on v4.6-rc3 for 32 bits x86. This patch > > applies cleanly to that rc. > > > > Has anyone had a chance to look at this patch, and perhaps even test > > it? > > Test? Nope. Seems obviously correct. This warning still shows up when building v4.7-rc3 for 32 bits x86. Since my previous message an entry for this driver showed up in MAINTAINERS. So I'd guess Sinclair, Thomas, etc want me to resend this small patch. Is that correct? Thanks, Paul Bolle
[PATCH v6] drm/rockchip: hdmi: add Innosilicon HDMI support
On ma, 2016-01-25 at 09:47 +0800, Yakir Yang wrote:
> --- a/drivers/gpu/drm/rockchip/Kconfig
> +++ b/drivers/gpu/drm/rockchip/Kconfig
> +config ROCKCHIP_INNO_HDMI
> + tristate "Rockchip specific extensions for Innosilicon HDMI"
> +depends on DRM_ROCKCHIP
> +help
> + This selects support for Rockchip SoC specific extensions
> + for the Innosilicon HDMI driver. If you want to enable
> + HDMI on RK3036 based SoC, you should selet this option.
(Really trivial: start indentation with tabs only, please. And
s/selet/select/.)
> --- /dev/null
> +++ b/drivers/gpu/drm/rockchip/inno_hdmi.c
> + * This software is licensed under the terms of the GNU General
> Public
> + * License version 2, as published by the Free Software Foundation,
> and
> + * may be copied, distributed, and modified under those terms.
This states this file is licensed GPL v2 only.
> +MODULE_LICENSE("GPL");
And, according to include/linux/module.h, this means "GNU Public License
v2 or later".
So I think there's a (subtle) mismatch between the license ident used
for this driver and the comment above.
Thanks,
Paul Bolle
[PATCH v2 6/6] drm: Add helper for simple display pipeline
On wo, 2016-05-11 at 19:09 +0200, Daniel Vetter wrote: > On Wed, May 11, 2016 at 06:09:22PM +0200, Noralf Trønnes wrote: > > --- a/drivers/gpu/drm/Kconfig > > +++ b/drivers/gpu/drm/Kconfig > > +config DRM_SIMPLE_KMS_HELPER > > + tristate > > + depends on DRM > > + select DRM_KMS_HELPER > > + help > > + Helpers for very simple KMS drivers. > > Personally not sold on piles of Kconfig knobs for tiny amounts of code > like this one. I'd just drop it. For a more elaborate argument see > http://sietch-tagr.blogspot.ch/2016/04/display-panels-are-not-special.html > > Note that almost all the other helpers do not have a Kconfig option, the > only real exception is the fbdev helpers. And those have a good reason: > They'd drag in all of fbdev, and that is actually a pile of code. Moreover, this adds a kconfig entry without a prompt. The entry also doesn't have a "default". And I didn't spot a patch adding a select for this symbol. So, based on just this series, I think that DRM_SIMPLE_KMS_HELPER can't actually be set. I didn't test this, so perhaps I missed something. Did I, Noralf? Paul Bolle
[PATCH] drm/vmwgfx: use *_32_bits() macros
Use the upper_32_bits() macro instead of the four line equivalent that triggers a GCC warning on 32 bits x86: drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function 'vmw_cmdbuf_header_submit': drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:297:25: warning: right shift count >= width of type [-Wshift-count-overflow] val = (header->handle >> 32); ^ And use the lower_32_bits() macro instead of and-ing with a 32 bits mask. Signed-off-by: Paul Bolle --- Note: compile tested only (I don't use any of vmware's products). drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c index 67cebb23c940..aa04fb0159a7 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c @@ -293,13 +293,10 @@ static int vmw_cmdbuf_header_submit(struct vmw_cmdbuf_header *header) struct vmw_cmdbuf_man *man = header->man; u32 val; - if (sizeof(header->handle) > 4) - val = (header->handle >> 32); - else - val = 0; + val = upper_32_bits(header->handle); vmw_write(man->dev_priv, SVGA_REG_COMMAND_HIGH, val); - val = (header->handle & 0xULL); + val = lower_32_bits(header->handle); val |= header->cb_context & SVGA_CB_CONTEXT_MASK; vmw_write(man->dev_priv, SVGA_REG_COMMAND_LOW, val); -- 2.4.3
[PATCH 2/3] drm:msm: Initial Add Writeback Support
A few nits follow.
On Wed, 2015-04-01 at 17:12 -0400, Jilai Wang wrote:
> --- a/drivers/gpu/drm/msm/Kconfig
> +++ b/drivers/gpu/drm/msm/Kconfig
> +config DRM_MSM_WB
> + bool "Enable writeback support for MSM modesetting driver"
> + depends on DRM_MSM
> + depends on VIDEO_V4L2
> + select VIDEOBUF2_CORE
> + default y
> + help
> + Choose this option if you have a need to support writeback
> + connector.
DRM_MSM_WB is a bool symbol...
> --- a/drivers/gpu/drm/msm/Makefile
> +++ b/drivers/gpu/drm/msm/Makefile
> +msm-$(CONFIG_DRM_MSM_WB) += \
> + mdp/mdp5/mdp5_wb_encoder.o \
> + mdp/mdp_wb/mdp_wb.o \
> + mdp/mdp_wb/mdp_wb_connector.o \
> + mdp/mdp_wb/mdp_wb_v4l2.o
so mdp_wb_v4l2.o will never be part of a module.
> --- /dev/null
> +++ b/drivers/gpu/drm/msm/mdp/mdp_wb/mdp_wb_v4l2.c
> +#include
This include is needed mostly for module_param(), right?
> +#define MSM_WB_MODULE_NAME "msm_wb"
MSM_WB_DRIVER_NAME? But see below.
> +static unsigned debug;
> +module_param(debug, uint, 0644);
debug is basically a boolean type of flag. Would
static bool debug;
module_param(debug, bool, 0644);
work?
> +MODULE_PARM_DESC(debug, "activates debug info");
No one is ever going to see this description.
> +#define dprintk(dev, level, fmt, arg...) \
> + v4l2_dbg(level, debug, >v4l2_dev, fmt, ## arg)
All instances of dprintk() that I found had level set to 1, so the above
could be simplified a bit:
#define dprintk(dev, fmt, arg...) \
v4l2_dbg(1, debug, >v4l2_dev, fmt, ## arg)
But perhaps pr_debug() and the dynamic debug facility could be used
instead of module_param(), dprintk() and v4l2_dbg(). Not sure which
approach is easier.
> +static const struct v4l2_file_operations msm_wb_v4l2_fops = {
> + .owner = THIS_MODULE,
THIS_MODULE will basically be equivalent to NULL.
> + .open = v4l2_fh_open,
> + .release = vb2_fop_release,
> + .poll = vb2_fop_poll,
> + .unlocked_ioctl = video_ioctl2,
> +};
> +int msm_wb_v4l2_init(struct msm_wb *wb)
> +{
> + struct msm_wb_v4l2_dev *dev;
> + struct video_device *vfd;
> + struct vb2_queue *q;
> + int ret;
> +
> + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> + if (!dev)
> + return -ENOMEM;
> +
> + snprintf(dev->v4l2_dev.name, sizeof(dev->v4l2_dev.name),
> + "%s", MSM_WB_MODULE_NAME);
It looks like you can actually drop the #define and merge the last two
arguments to snprintf() into just "msm_wb".
> + ret = v4l2_device_register(NULL, >v4l2_dev);
> + if (ret)
> + goto free_dev;
> +
> + /* default ARGB 640x480 */
> + dev->fmt = get_format(V4L2_PIX_FMT_RGB32);
> + dev->width = 640;
> + dev->height = 480;
> +
> + /* initialize queue */
> + q = >vb_vidq;
> + q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
> + q->io_modes = VB2_DMABUF;
> + q->drv_priv = dev;
> + q->buf_struct_size = sizeof(struct msm_wb_v4l2_buffer);
> + q->ops = _wb_vb2_ops;
> + q->mem_ops = _wb_vb2_mem_ops;
> + q->timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> +
> + ret = vb2_queue_init(q);
> + if (ret)
> + goto unreg_dev;
> +
> + mutex_init(>mutex);
> +
> + vfd = >vdev;
> + *vfd = msm_wb_v4l2_template;
> + vfd->debug = debug;
I couldn't find a member of struct video_device named debug. Where does
that come from? Because, as far as I can see, this won't compile.
> + vfd->v4l2_dev = >v4l2_dev;
> + vfd->queue = q;
> +
> + /*
> + * Provide a mutex to v4l2 core. It will be used to protect
> + * all fops and v4l2 ioctls.
> + */
> + vfd->lock = >mutex;
> + video_set_drvdata(vfd, dev);
> +
> + ret = video_register_device(vfd, VFL_TYPE_GRABBER, -1);
> + if (ret < 0)
> + goto unreg_dev;
> +
> + dev->wb = wb;
> + wb->wb_v4l2 = dev;
> + v4l2_info(>v4l2_dev, "V4L2 device registered as %s\n",
> + video_device_node_name(vfd));
> +
> + return 0;
> +
> +unreg_dev:
> + v4l2_device_unregister(>v4l2_dev);
> +free_dev:
> + kfree(dev);
> + return ret;
> +}
Paul Bolle
[PATCH 2/3] drm:msm: Initial Add Writeback Support
Hi Jilai,
On Thu, 2015-04-02 at 17:58 +, jilaiw at codeaurora.org wrote:
> Thanks Paul. Some comments embedded and for the rest I will update the
> code accordingly.
Most of my comments appear to be ill informed, so I wouldn't mind if
you'd specify which updates you actually plan to do.
> >> --- a/drivers/gpu/drm/msm/Makefile
> >> +++ b/drivers/gpu/drm/msm/Makefile
> >
> >> +msm-$(CONFIG_DRM_MSM_WB) += \
> >> + mdp/mdp5/mdp5_wb_encoder.o \
> >> + mdp/mdp_wb/mdp_wb.o \
> >> + mdp/mdp_wb/mdp_wb_connector.o \
> >> + mdp/mdp_wb/mdp_wb_v4l2.o
> >
> > so mdp_wb_v4l2.o will never be part of a module.
> If CONFIG-DRM_MSM_WB is y, then all wb related files (including
> mdp_wb_v4l2.o) will be added to msm-y, then be linked to msm.o
> obj-$(CONFIG_DRM_MSM) += msm.o
(A tell tale was that I didn't quote that line.)
> Refer to document http://lwn.net/Articles/21835/ (section 3.3),
> it should be able to be built-in to kernel or as a module.
It's hard typing with a brown paper bag for headware: I still have
trouble speaking Makefile, even after all these years, but I'm afraid
you're right.
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/msm/mdp/mdp_wb/mdp_wb_v4l2.c
> >
> >> +#include
> >
> > This include is needed mostly for module_param(), right?
> >
> >> +#define MSM_WB_MODULE_NAME "msm_wb"
> >
> > MSM_WB_DRIVER_NAME? But see below.
> >
> >> +static unsigned debug;
> >> +module_param(debug, uint, 0644);
> >
> > debug is basically a boolean type of flag. Would
> > static bool debug;
> > module_param(debug, bool, 0644);
> >
> > work?
> >
> >> +MODULE_PARM_DESC(debug, "activates debug info");
> >
> > No one is ever going to see this description.
> >
> >> +#define dprintk(dev, level, fmt, arg...) \
> >> + v4l2_dbg(level, debug, >v4l2_dev, fmt, ## arg)
> >
> > All instances of dprintk() that I found had level set to 1, so the above
> > could be simplified a bit:
> > #define dprintk(dev, fmt, arg...) \
> > v4l2_dbg(1, debug, >v4l2_dev, fmt, ## arg)
> >
> > But perhaps pr_debug() and the dynamic debug facility could be used
> > instead of module_param(), dprintk() and v4l2_dbg(). Not sure which
> > approach is easier.
> >
> >> +static const struct v4l2_file_operations msm_wb_v4l2_fops = {
> >> + .owner = THIS_MODULE,
> >
> > THIS_MODULE will basically be equivalent to NULL.
> >
> >> + .open = v4l2_fh_open,
> >> + .release = vb2_fop_release,
> >> + .poll = vb2_fop_poll,
> >> + .unlocked_ioctl = video_ioctl2,
> >> +};
> >
> >> +int msm_wb_v4l2_init(struct msm_wb *wb)
> >> +{
> >> + struct msm_wb_v4l2_dev *dev;
> >> + struct video_device *vfd;
> >> + struct vb2_queue *q;
> >> + int ret;
> >> +
> >> + dev = kzalloc(sizeof(*dev), GFP_KERNEL);
> >> + if (!dev)
> >> + return -ENOMEM;
> >> +
> >> + snprintf(dev->v4l2_dev.name, sizeof(dev->v4l2_dev.name),
> >> + "%s", MSM_WB_MODULE_NAME);
> >
> > It looks like you can actually drop the #define and merge the last two
> > arguments to snprintf() into just "msm_wb".
> >
> >> + ret = v4l2_device_register(NULL, >v4l2_dev);
> >> + if (ret)
> >> + goto free_dev;
> >> +
> >> + /* default ARGB 640x480 */
> >> + dev->fmt = get_format(V4L2_PIX_FMT_RGB32);
> >> + dev->width = 640;
> >> + dev->height = 480;
> >> +
> >> + /* initialize queue */
> >> + q = >vb_vidq;
> >> + q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
> >> + q->io_modes = VB2_DMABUF;
> >> + q->drv_priv = dev;
> >> + q->buf_struct_size = sizeof(struct msm_wb_v4l2_buffer);
> >> + q->ops = _wb_vb2_ops;
> >> + q->mem_ops = _wb_vb2_mem_ops;
> >> + q->timestamp_type = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
> >> +
> >> + ret = vb2_queue_init(q);
> >> + if (ret)
> >> + goto unreg_dev;
> >> +
> >> + mutex_init(>mutex);
> >> +
> >> + vfd = >vdev;
> >> + *vfd = msm_wb_v4l2_template;
> >> + vfd->debug = debug;
> >
> > I couldn't find a member of struct video_device named debug. Where does
> > that come from? Because, as far as I can see, this won't compile.
> yes, it's there:
> http://lxr.free-electrons.com/source/include/media/v4l2-dev.h#L127
Probably in some tree I'm not aware of. I only did:
$ git cat-file blob v4.0-rc6:include/media/v4l2-dev.h | grep debug
/* Internal device debug flags, not for use by drivers */
int dev_debug;
and
$ git cat-file blob next-20150402:include/media/v4l2-dev.h | grep debug
/* Internal device debug flags, not for use by drivers */
int dev_debug;
Which tree does debug come from?
Thanks,
Paul Bolle
[PATCH v2 1/4] break kconfig dependency loop
On Wed, 2015-04-01 at 16:47 +0300, Jani Nikula wrote: > I think part of the problem is that "select" is often used not as > documented [1] but rather as "show my config in menuconfig for > convenience even if my dependency is not met, and select the dependency > even though I know it can screw up the dependency chain". Perhaps people use select because it offers, given the problem they face, a reasonable way to make the kconfig tools generate a sensible .config. It helps them to spend less time fiddling with Kconfig files. And they expect that it helps others to configure their build more easily, as it might save those others some work. > In the big picture, it feels like menuconfig needs a way to display > items whose dependencies are not met, and a way to recursively enable > said items and all their dependencies when told. How could that work its way through (multiple levels of) things like: depends on FOO || (BAZ && BAR) > This would reduce the > resistance to sticking with "select" when clearly "depends" is what's > meant. I had drafted a rather verbose response to this. But I think I'm not really sure what you're saying here, probably because "select" and "depends on" are rather different. How would you know that the actual intention was to use "depends on"? Paul Bolle
drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING
On Thu, 2015-04-09 at 19:07 +0200, Greg KH wrote: > I really don't understand. Why is this code in the kernel tree if it > can't be built? How does anyone use this? By taking it and copying it > where? If it can't be built, and no one can update it, and of course > not run it, why is it here? What good is this code doing sitting here? The Erlangen bot (courtesy of Valentin, Stefan, and Andreas) has taken over what I've been doing for quite some time, but doing it much more thoroughly. And my experience tells me that the reports they'll send in will trigger more discussions like this one. A lesson I learned from my daily checks for Kconfig oddities is that people go to great lengths defending unbuildable code. (Do a web search for ATHEROS_AR231X to find a discussion that dragged on for over three years!) Personally I stopped caring after someone insisted on having a file in the tree that was in no way connected to the build system: not a single line in any of the Makefiles pointed at it. So, as far as I'm concerned, if people can't point at a patch pending, somehow, somewhere, that would make their code buildable one might as well delete the code. I really think it's as simple as that. Paul Bolle
drm/msm/mdp5: undefined CONFIG_MSM_BUS_SCALING
On Thu, 2015-04-09 at 14:54 -0400, Rob Clark wrote: > We are talking about a driver which does build and run on > upstream kernel, and which has a few small #ifdef blocks to simplify > backporting to downstream kernels (which we still do need to use for > some generations and some devices) This has comes up before too. My thoughts are basically that since it's just a few blocks of code (I think we're discussing less than 200 lines of code split over nine files here) it's hard to see why it would be such a burden to carry those blocks in a separate tree until everything can be submitted in actual working condition. Paul Bolle
[PATCH] drm/nouveau/fb: mark ramfuc_reg() noinline
Building ramnve0.o triggers a GCC warning on 32 bits x86:
drivers/gpu/drm/nouveau/core/subdev/fb/ramnve0.c: In function
'nve0_ram_ctor':
drivers/gpu/drm/nouveau/core/subdev/fb/ramnve0.c:1253:1: warning: the frame
size of 1496 bytes is larger than 1024 bytes [-Wframe-larger-than=]
This warning is caused by ramfuc_reg(), which is inlined 74 times in
nve0_ram_ctor(). Mark it noinline to silence this warning.
Signed-off-by: Paul Bolle
---
Compile tested (on 32 bits x86) only. I've no Nvidia cards at hand, so I
can't really test it.
This assumes this function - a constructor, apparently - isn't called
often, so the overhead calling of 74 functions is acceptable. (The same
goes for the similar functions in [...]/ramnva3.c and in
[...]/ramnvc0.c, though these call ramfuc_reg() not quite as often.)
Perhaps there are other downsides to not inlining this function too. So
proper testing will probably be needed.
drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h
b/drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h
index 0f57fcf..04e3849 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h
+++ b/drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h
@@ -26,7 +26,7 @@ ramfuc_reg2(u32 addr1, u32 addr2)
};
}
-static inline struct ramfuc_reg
+static noinline struct ramfuc_reg
ramfuc_reg(u32 addr)
{
return ramfuc_reg2(addr, addr);
--
1.8.4.2
[git pull] drm next tree
Dave Airlie schreef op do 30-01-2014 om 02:49 [+]: > Christian K?nig (10): > [...] > drm/radeon: add GART debugfs access v3 > [...] That one generates a bit of (warning) noise when building on 32 bits x86: In file included from include/asm-generic/bug.h:13:0, from [...]/linux/arch/x86/include/asm/bug.h:38, from include/linux/bug.h:4, from include/drm/drm_mm.h:39, from include/drm/drm_vma_manager.h:26, from include/drm/ttm/ttm_bo_api.h:35, from drivers/gpu/drm/radeon/radeon_ttm.c:32: drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_gtt_read': include/linux/kernel.h:712:17: warning: comparison of distinct pointer types lacks a cast [enabled by default] (void) (&_min1 == &_min2); \ ^ drivers/gpu/drm/radeon/radeon_ttm.c:938:22: note: in expansion of macro 'min' ssize_t cur_size = min(size, PAGE_SIZE - off); ^ I suppose the last line should read ssize_t cur_size = min(size, (size_t) PAGE_SIZE - off); to silence this. But I haven't tested yet. Paul Bolle
drm: i915: "plane B assertion failure, should be off on pipe B but is still active"
On Tue, 2014-07-01 at 12:17 +0300, Jani Nikula wrote: > This does not ring any bells to me (but that doesn't prove anything). A > bisect result would be awesome. Too bad. Unless someone else has a better idea I hope to start bisecting one of these days (that might take quite some time, especially since I can't yet narrow the bisect to changes in drivers/gpu/drm/i915/, can I?). Don't expect results before v3.16-rc4. Feel free to remind me if I stay silent on this subject for too long. Paul Bolle
drm: i915: "plane B assertion failure, should be off on pipe B but is still active"
Paul Bolle schreef op wo 02-07-2014 om 10:53 [+0200]:
> On Tue, 2014-07-01 at 12:17 +0300, Jani Nikula wrote:
> > This does not ring any bells to me (but that doesn't prove anything). A
> > bisect result would be awesome.
The bisect (which took me quite some time) points at commit 98ec77397a5c
("drm/i915: Make primary_enabled match the actual hardware state"). The
bisect log is pasted at the end of this message.
Commit 98ec77397a5c reverts cleanly on top of v3.16-rc4. Booting
v3.16-rc4 with that revert added makes the WARNING go away. But note
that I have no idea whether that revert actually is a proper fix here.
Feel free to prod me for further testing, etc.
Paul Bolle
# bad: [7171511eaec5bf23fb06078f59784a3a0626b38f] Linux 3.16-rc1
# good: [1860e379875dfe7271c649058aeddffe5afd9d0d] Linux 3.15
git bisect start 'v3.16-rc1' 'v3.15'
# good: [aaeb2554337217dfa4eac2fcc90da7be540b9a73] Merge branch 'v4l_for_linus'
of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media into next
git bisect good aaeb2554337217dfa4eac2fcc90da7be540b9a73
# good: [16b9057804c02e2d351e9c8f606e909b43cbd9e7] Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect good 16b9057804c02e2d351e9c8f606e909b43cbd9e7
# good: [249c8b8d7e2d1bf9505dc46458537e77326c24fd] i40evf: remove unnecessary
log messages
git bisect good 249c8b8d7e2d1bf9505dc46458537e77326c24fd
# bad: [1ae5a62bb8b6b544bdfac7bdcb15c9eb22dd6620] drm/nouveau/disp/dp: fix tmds
passthrough on dp connector
git bisect bad 1ae5a62bb8b6b544bdfac7bdcb15c9eb22dd6620
# bad: [cea165c34502052cb2aafc7e6bb36fe2036a19df] drm/i915: Wait for vblank in
hsw_enable_ips()
git bisect bad cea165c34502052cb2aafc7e6bb36fe2036a19df
# good: [e6069ca84dfafbfdbd0d429445b5858ec5b090ac] drm/i915: sanitize
enable_rc6 option
git bisect good e6069ca84dfafbfdbd0d429445b5858ec5b090ac
# bad: [aff10b30a1d3edd1e31f536648772da85e33f655] drm/i915: Don't drop pinned
fences
git bisect bad aff10b30a1d3edd1e31f536648772da85e33f655
# bad: [3f1d896c61e889e5b1a0cc0c0211574fa76feefb] drm/i915/chv: Enable aliasing
PPGTT for CHV
git bisect bad 3f1d896c61e889e5b1a0cc0c0211574fa76feefb
# good: [0d116a29a8f80260380f608c033dba42240e26a8] drm/i915: vlv: init only
needed state during early power well enabling
git bisect good 0d116a29a8f80260380f608c033dba42240e26a8
# bad: [894ed1ec4818ad12e5254de33de2fe5cf2ab987b] drm/i915/crt: Remove
->mode_set callback
git bisect bad 894ed1ec4818ad12e5254de33de2fe5cf2ab987b
# bad: [912b0e2dc6779d70a549dc90b0884face3b2540a] drm/i915/dvo: Remove
->mode_set callback
git bisect bad 912b0e2dc6779d70a549dc90b0884face3b2540a
# good: [024a43e12cccd13b7336fc71ab2067a19ade1857] drm/i915: Move ring_begin to
signal()
git bisect good 024a43e12cccd13b7336fc71ab2067a19ade1857
# bad: [0d56bf0b65e6930ea00060d4107414b8d74c9055] drm/i915: Make
encoder->mode_set callbacks optional
git bisect bad 0d56bf0b65e6930ea00060d4107414b8d74c9055
# bad: [98ec77397a5c68ce753dc283aaa6f4742328bcdd] drm/i915: Make
primary_enabled match the actual hardware state
git bisect bad 98ec77397a5c68ce753dc283aaa6f4742328bcdd
# first bad commit: [98ec77397a5c68ce753dc283aaa6f4742328bcdd] drm/i915: Make
primary_enabled match the actual hardware state
drm: i915: "plane B assertion failure, should be off on pipe B but is still active"
On Mon, 2014-07-14 at 08:56 +0200, Daniel Vetter wrote: > Please test the below patch, thanks. > -Daniel > > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 82e7d57f0a8a..f0be855ddf45 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -11914,6 +11914,7 @@ static void intel_sanitize_crtc(struct intel_crtc > *crtc) >* ... */ > plane = crtc->plane; > crtc->plane = !plane; > + crtc->primary_enabled = true; > dev_priv->display.crtc_disable(>base); > crtc->plane = plane; > Instead of the revert or on top of the revert? Thanks, Paul Bolle
drm: i915: "plane B assertion failure, should be off on pipe B but is still active"
Daniel Vetter schreef op ma 14-07-2014 om 09:18 [+0200]: > On Mon, Jul 14, 2014 at 09:13:40AM +0200, Paul Bolle wrote: > > On Mon, 2014-07-14 at 08:56 +0200, Daniel Vetter wrote: > > > diff --git a/drivers/gpu/drm/i915/intel_display.c > > > b/drivers/gpu/drm/i915/intel_display.c > > > index 82e7d57f0a8a..f0be855ddf45 100644 > > > --- a/drivers/gpu/drm/i915/intel_display.c > > > +++ b/drivers/gpu/drm/i915/intel_display.c > > > @@ -11914,6 +11914,7 @@ static void intel_sanitize_crtc(struct intel_crtc > > > *crtc) > > >* ... */ > > > plane = crtc->plane; > > > crtc->plane = !plane; > > > + crtc->primary_enabled = true; > > > dev_priv->display.crtc_disable(>base); > > > crtc->plane = plane; > > > > > > > Instead of the revert or on top of the revert? > > Instead of the revert as an attempt at a proper bugfix. If it doesn't work > my theory about what's going on on your machine is all wrong ;-) v3.16-rc5 with that "attempt at a proper bugfix" applied doesn't show the WARNING anymore. Please note that I didn't actually bother to test whether v3.16-rc5 by itself, somehow, fixed things. I guess that's rather unlikely. But if you'd like to be sure I'll even build and boot v3.16-rc5 without your attempt at a bugfix. Thanks! Paul Bolle
drm/i915: CONFIG_DRM_I915_UMS
Daniel,
Your commit 2225a28fd916 ("drm/i915: Ditch UMS config option") is
included in today's linux-next (ie, next-20140725). It removes the
Kconfig symbol DRM_I915_UMS.
It didn't remove the two (negative) checks for CONFIG_DRM_I915_UMS.
These checks are superfluous as they now will always evaluate to true.
Is the trivial cleanup to remove them already queued somewhere?
Paul Bolle
drm/i915: CONFIG_DRM_I915_UMS
On Sat, 2014-07-26 at 01:44 +0200, Daniel Vetter wrote:
> On Fri, Jul 25, 2014 at 2:14 PM, Paul Bolle wrote:
> > Your commit 2225a28fd916 ("drm/i915: Ditch UMS config option") is
> > included in today's linux-next (ie, next-20140725). It removes the
> > Kconfig symbol DRM_I915_UMS.
> >
> > It didn't remove the two (negative) checks for CONFIG_DRM_I915_UMS.
> > These checks are superfluous as they now will always evaluate to true.
> > Is the trivial cleanup to remove them already queued somewhere?
>
> No, and intentionally.
So this was not by mistake, which is good to know.
> Actually removing the code for
> user-mode-setting isn't just removing these two blocks,
Just to be clear: I'm only suggesting to remove the two lines reading
#ifndef CONFIG_DRM_I915_UMS
and their corresponding #endif lines.
> but requires
> the gutting of roughly 10k lines splattered all over the driver.
> Essentially all the code that checks for
> !drm_core_check_feature(DRIVER_MODESET) needs to go. That's not quite
> as trivial, and before I do that I want to make really sure that
> really no one misses this option.
>
> So probably after 3.17 is out the door for a bit.
None of what I brought up is urgent. But I do hope you don't mind me
sending a reminder if these few (preprocessor) lines are staying around
longer than expected.
Paul Bolle
drm/i915: "Wrong MCH_SSKPD value: 0x16040307"
0) A ThinkPad X220 I use prints these messages at every boot and at every resume: [drm] Wrong MCH_SSKPD value: 0x16040307 [drm] This can cause pipe underruns and display issues. [drm] Please upgrade your BIOS to fix this. These messages can be seen for every kernel that's still in the logs (the oldest is v3.11 based). 1) I'm not sure whether I actually run into "pipe underruns" or "display issues". Is there something specific I should look for? 2) Now it happens that this laptop already runs the latest BIOS. So, if I were to contact Lenovo to see if they could release a BIOS update to fix this, what should I ask them to do? Paul Bolle
drm: i915: "plane B assertion failure, should be off on pipe B but is still active"
Kernels v3.16-rc2 and v3.16-rc3 trigger a new (for me) warning. (I never booted v3.16-rc1). Machine is a, rather outdated, ThinkPad X41 (ie, single core i686). WARNING: CPU: 0 PID: 221 at drivers/gpu/drm/i915/intel_display.c:1274 assert_planes_disabled+0xf9/0x100 [i915]() plane B assertion failure, should be off on pipe B but is still active Modules linked in: tg3 i915(+) i2c_algo_bit drm_kms_helper ptp drm ata_generic pata_acpi yenta_socket i2c_core pps_core video CPU: 0 PID: 221 Comm: systemd-udevd Not tainted 3.16.0-0.rc3.1.local0.fc20.i686 #1 Hardware name: IBM 2525FAG/2525FAG, BIOS 74ET64WW (2.09 ) 12/14/2006 c0c87907 add7c490 f652b9ac c09fdab7 f652b9ec f652b9dc c045008e f830c6cc f652ba0c 00dd f830c634 04fa f82b4d59 f82b4d59 f6728000 0001 f65a8c00 f652b9f8 c04500ee 0009 f652b9ec f830c6cc f652ba0c Call Trace: [] dump_stack+0x41/0x52 [] warn_slowpath_common+0x7e/0xa0 [] ? assert_planes_disabled+0xf9/0x100 [i915] [] ? assert_planes_disabled+0xf9/0x100 [i915] [] warn_slowpath_fmt+0x3e/0x60 [] assert_planes_disabled+0xf9/0x100 [i915] [] intel_disable_pipe+0x26/0xb0 [i915] [] ? gen4_read8+0xc0/0xc0 [i915] [] i9xx_crtc_disable+0x93/0x3d0 [i915] [] intel_modeset_setup_hw_state+0x7ac/0xbc0 [i915] [] ? gen4_read8+0xc0/0xc0 [i915] [] ? drm_modeset_lock_all_crtcs+0x3c/0x50 [drm] [] intel_modeset_init+0x734/0x1220 [i915] [] ? i915_enable_pipestat+0xab/0x120 [i915] [] ? i915_irq_postinstall+0x104/0x110 [i915] [] ? drm_irq_install+0xa9/0x170 [drm] [] i915_driver_load+0xa76/0xe70 [i915] [] ? i915_switcheroo_set_state+0x90/0x90 [i915] [] ? cleanup_uevent_env+0x10/0x10 [] ? sysfs_add_file+0x23/0x30 [] ? get_device+0x14/0x30 [] ? klist_class_dev_get+0x12/0x20 [] ? klist_node_init+0x2e/0x50 [] ? klist_add_tail+0x27/0x30 [] ? device_add+0x1d6/0x5a0 [] ? drm_sysfs_device_add+0xba/0x100 [drm] [] drm_dev_register+0x8e/0xe0 [drm] [] drm_get_pci_dev+0x79/0x1c0 [drm] [] i915_pci_probe+0x35/0x60 [i915] [] pci_device_probe+0x6f/0xc0 [] ? sysfs_create_link+0x25/0x40 [] driver_probe_device+0x93/0x3a0 [] ? sysfs_create_dir_ns+0x37/0x80 [] ? pci_match_device+0xc1/0xe0 [] __driver_attach+0x71/0x80 [] ? __device_attach+0x40/0x40 [] bus_for_each_dev+0x57/0xa0 [] driver_attach+0x1e/0x20 [] ? __device_attach+0x40/0x40 [] bus_add_driver+0x157/0x230 [] ? 0xf7fc7fff [] ? 0xf7fc7fff [] driver_register+0x59/0xe0 [] ? __kmalloc_track_caller+0x46/0x1f0 [] __pci_register_driver+0x32/0x40 [] drm_pci_init+0xe5/0x110 [drm] [] ? 0xf7fc7fff [] i915_init+0x88/0x8a [i915] [] ? 0xf7fc7fff [] do_one_initcall+0xc2/0x1f0 [] ? 0xf7fc7fff [] ? kfree+0xdd/0x120 [] ? __vunmap+0x8f/0xe0 [] ? __vunmap+0x8f/0xe0 [] ? __vunmap+0x8f/0xe0 [] load_module+0x1a92/0x23b0 [] ? copy_module_from_fd.isra.46+0x109/0x1a0 [] SyS_finit_module+0x8d/0xd0 [] ? vm_mmap_pgoff+0x93/0xb0 [] sysenter_do_call+0x12/0x16 Feel free to prod me for further details. Paul Bolle
3.13 i915 brightness settings broken when going from docked -> undocked
On Tue, 2014-02-25 at 10:05 +0200, Jani Nikula wrote: > On Thu, 20 Feb 2014, Paul Bolle wrote: > > On an (rather old) ThinkPad X41, which also uses i915, brightness > > adjustments stopped working altogether in v3.14-rc1 (I haven't used its > > docking station in the v3.14 release cycle). In v3.13.y things behave as > > expected. So perhaps there's actually a more general problem here. > > I presume different problems. Does the ThinkPad X41 have gen3 graphics? > (See e.g. /sys/kernel/debug/dri/0/i915_capabilities) If yes, it might be > https://bugs.freedesktop.org/show_bug.cgi?id=75001 Yes, it has "gen3" graphics (a 915GM). And applying your patch "drm/i915: use backlight legacy combination mode also for i915gm/i945/gm" on top of v3.14-rc5 fixes the issue on that ThinkPad X41. Thanks, Paul Bolle
[PATCH v2] drm/radeon: silence GCC warning on 32 bit
Building radeon_ttm.o on 32 bit x86 triggers a warning:
In file included from include/asm-generic/bug.h:13:0,
from [...]/arch/x86/include/asm/bug.h:38,
from include/linux/bug.h:4,
from include/drm/drm_mm.h:39,
from include/drm/drm_vma_manager.h:26,
from include/drm/ttm/ttm_bo_api.h:35,
from drivers/gpu/drm/radeon/radeon_ttm.c:32:
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_gtt_read':
include/linux/kernel.h:712:17: warning: comparison of distinct pointer
types lacks a cast [enabled by default]
(void) (&_min1 == &_min2); \
^
drivers/gpu/drm/radeon/radeon_ttm.c:938:22: note: in expansion of macro
'min'
ssize_t cur_size = min(size, PAGE_SIZE - off);
^
Silence this warning by using min_t(). Since cur_size will never be
negative and its upper bound is PAGE_SIZE, we can change its type to
size_t and use min_t(size_t, [...]) here.
Signed-off-by: Paul Bolle
---
v2: use min_t() as Ilia suggested, and convert cur_size to size_t, as
Thierry suggested.
Still compile tested only (on 32 and 64 bit x86).
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 77f5b0c..1ce6ba6 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -935,7 +935,7 @@ static ssize_t radeon_ttm_gtt_read(struct file *f, char
__user *buf,
while (size) {
loff_t p = *pos / PAGE_SIZE;
unsigned off = *pos & ~PAGE_MASK;
- ssize_t cur_size = min(size, PAGE_SIZE - off);
+ size_t cur_size = min_t(size_t, size, PAGE_SIZE - off);
struct page *page;
void *ptr;
--
1.8.5.3
[PATCH] drm/nouveau/fb: mark ramfuc_reg() noinline
Paul Bolle schreef op vr 10-01-2014 om 11:37 [+0100]:
> Building ramnve0.o triggers a GCC warning on 32 bits x86:
> drivers/gpu/drm/nouveau/core/subdev/fb/ramnve0.c: In function
> 'nve0_ram_ctor':
> drivers/gpu/drm/nouveau/core/subdev/fb/ramnve0.c:1253:1: warning: the
> frame size of 1496 bytes is larger than 1024 bytes [-Wframe-larger-than=]
>
> This warning is caused by ramfuc_reg(), which is inlined 74 times in
> nve0_ram_ctor(). Mark it noinline to silence this warning.
>
> Signed-off-by: Paul Bolle
> ---
> Compile tested (on 32 bits x86) only. I've no Nvidia cards at hand, so I
> can't really test it.
>
> This assumes this function - a constructor, apparently - isn't called
Here "this function" refers to nve0_ram_ctor().
> often, so the overhead calling of 74 functions is acceptable. (The same
> goes for the similar functions in [...]/ramnva3.c and in
> [...]/ramnvc0.c, though these call ramfuc_reg() not quite as often.)
> Perhaps there are other downsides to not inlining this function too. So
And here it refers to ramfuc_reg(). So my writing was a bit confusing.
> proper testing will probably be needed.
Building v3.14-rc5 on 32 bit x86 still triggers this warning. Has anyone
tried to review or test this patch?
Paul Bolle
> drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h
> b/drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h
> index 0f57fcf..04e3849 100644
> --- a/drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h
> +++ b/drivers/gpu/drm/nouveau/core/subdev/fb/ramfuc.h
> @@ -26,7 +26,7 @@ ramfuc_reg2(u32 addr1, u32 addr2)
> };
> }
>
> -static inline struct ramfuc_reg
> +static noinline struct ramfuc_reg
> ramfuc_reg(u32 addr)
> {
> return ramfuc_reg2(addr, addr);
[PATCH v5 08/24] amdkfd: Add amdkfd skeleton driver
On Sat, 2014-11-08 at 20:37 +0200, Oded Gabbay wrote: > This patch adds the amdkfd skeleton driver. The driver does nothing except > define a /dev/kfd device. > > It returns -ENODEV on all amdkfd IOCTLs. > > v3: Move bool field to the end of structure, removed the pmc ioctls and added > a meaningful error message for ioctl error. > > v5: > > Create a new folder drm/amd and move amdkfd from drm/radeon/ to drm/amd/ > Remove scheduler_class from kfd_priv.h as it was never used > Add skeleton implementation of the Get Version IOCTL > > Signed-off-by: Oded Gabbay It seems v6 of this patch is included in today's linux-next (ie, next-20141121). > drivers/gpu/drm/Kconfig | 2 + > drivers/gpu/drm/Makefile | 1 + > drivers/gpu/drm/amd/amdkfd/Kconfig | 10 ++ > drivers/gpu/drm/amd/amdkfd/Makefile | 9 ++ > drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 210 > +++ > drivers/gpu/drm/amd/amdkfd/kfd_device.c | 130 +++ > drivers/gpu/drm/amd/amdkfd/kfd_module.c | 101 +++ > drivers/gpu/drm/amd/amdkfd/kfd_priv.h| 81 > 8 files changed, 544 insertions(+) > [...] > diff --git a/drivers/gpu/drm/amd/amdkfd/Kconfig > b/drivers/gpu/drm/amd/amdkfd/Kconfig > new file mode 100644 > index 000..a2ae6d4 > --- /dev/null > +++ b/drivers/gpu/drm/amd/amdkfd/Kconfig > @@ -0,0 +1,10 @@ > +# > +# Heterogenous system architecture configuration > +# > + > +config HSA_AMD > + tristate "HSA kernel driver for AMD GPU devices" > + depends on (DRM_RADEON || DRM_AMDGPU) && AMD_IOMMU_V2 && X86_64 There's currently no Kconfig symbol DRM_AMDGPU (nor anything similar). Will that symbol be added in a future patch? > + default m > + help > + Enable this if you want to use HSA features on AMD GPU devices. Paul Bolle
[PATCH] drm/tegra: fix typo 'CONFIG_TEGRA_DRM_FBDEV'
Signed-off-by: Paul Bolle
---
Entirely untested. But it's clear that this is what was intended.
drivers/gpu/drm/tegra/drm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 88a5290..c715947 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -104,7 +104,7 @@ static void tegra_drm_context_free(struct tegra_drm_context
*context)
static void tegra_drm_lastclose(struct drm_device *drm)
{
-#ifdef CONFIG_TEGRA_DRM_FBDEV
+#ifdef CONFIG_DRM_TEGRA_FBDEV
struct tegra_drm *tegra = drm->dev_private;
tegra_fbdev_restore_mode(tegra->fbdev);
--
1.8.5.3
drm/msm: CONFIG_MSM_OCMEM?
Rob,
Commit 55459968176f ("drm/msm: add a330/apq8x74") added preprocessor
checks for CONFIG_MSM_OCMEM. But I couldn't find a Kconfig symbol
MSM_OCMEM (nor a preprocessor define for a macro of that name). Why were
those preprocessor checks added?
Please note that lines 197-201 currently read:
/* Set the OCMEM base address for A330, etc */
if (a3xx_gpu->ocmem_hdl) {
gpu_write(gpu, REG_A3XX_RB_GMEM_BASE_ADDR,
(unsigned int)(a3xx_gpu->ocmem_base >> 14));
}
ocmem_hdl and ocmem_base are used uninitialized here, aren't they? So it
seems these lines should be wrapped with a preprocessor check for
CONFIG_MSM_OCMEM too.
Paul Bolle
drm/msm: CONFIG_MSM_OCMEM?
On Tue, 2014-02-11 at 12:29 -0500, Rob Clark wrote:
> On Tue, Feb 11, 2014 at 10:39 AM, Paul Bolle wrote:
> > Commit 55459968176f ("drm/msm: add a330/apq8x74") added preprocessor
> > checks for CONFIG_MSM_OCMEM. But I couldn't find a Kconfig symbol
> > MSM_OCMEM (nor a preprocessor define for a macro of that name). Why were
> > those preprocessor checks added?
>
> At the moment, CONFIG_MSM_OCMEM is only in downstream kernel.. not
> 100% sure about how we'll handle that upstream when there is more than
> just drm/msm using OCMEM (which can be shared between gpu, video
> enc/dec, etc).
I see. (Wouldn't that be an upstream kernel, actually?)
> > Please note that lines 197-201 currently read:
> > /* Set the OCMEM base address for A330, etc */
> > if (a3xx_gpu->ocmem_hdl) {
> > gpu_write(gpu, REG_A3XX_RB_GMEM_BASE_ADDR,
> > (unsigned int)(a3xx_gpu->ocmem_base >> 14));
> > }
> >
> > ocmem_hdl and ocmem_base are used uninitialized here, aren't they? So it
> > seems these lines should be wrapped with a preprocessor check for
> > CONFIG_MSM_OCMEM too.
>
> in this case ocmem_hdl will be NULL (since a3xx_gpu is kzalloc'd).
> The #ifdef's could be added here, but not required.
I missed that. So whether or not to #ifdef this would be mostly a matter
of style.
Thanks,
Paul Bolle
3.13 i915 brightness settings broken when going from docked -> undocked
On Wed, 2014-02-19 at 21:20 -0500, Josh Boyer wrote: > We've had a rather weird report[1] of the brightness adjustments being > broken in a specific case with Thinkpad x220 hardware (SandyBridge > based). If you boot the machine with it in a dock and then undock, > the brightness adjustments do not work. That is with either the FN > keys or the GNOME brightness slider. On an (rather old) ThinkPad X41, which also uses i915, brightness adjustments stopped working altogether in v3.14-rc1 (I haven't used its docking station in the v3.14 release cycle). In v3.13.y things behave as expected. So perhaps there's actually a more general problem here. > I can see that the value of > /sys/class/backlight/acpi_video0/brightness On the X41 I check /proc/acpi/ibm/brightness ... > increases/decreases but > /sys/class/backlight/intel_backlight/brightness doesn't reflect any > changes. but otherwise things look similar. > With 3.12 this works, and oddly with 3.14-rc1 it works > (specifically, it starts working around v3.13-10231-g53d8ab2 which is > right after the first DRM merge for 3.14). With 3.13, if I undock and > echo a higher value in the intel_backlight_brightness sysfs entry, the > brightness will actually increase so it can be done manually, but it > does not work as you'd expect. Echoing values into /sys/class/backlight/intel_backlight/brightness works too (that's a new trick for me!). But, again, no docking station is required, so the problem looks less odd than the problem on that x220. > I'm in the middle of trying to do a reverse bisect for which patch > fixes it in the 3.14-rcX series, but that's taking a while. I thought > I'd email and see if anyone already knows about this situation, what > patch in 3.13 broke this, and which one then fixed it again. Thus far > all I've gathered is that backlight handling is confusing. I haven't yet tried bisecting. > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1067071 Paul Bolle
[PATCH] drm/radeon: silence GCC warning on 32 bit
Building radeon_ttm.o on 32 bit x86 triggers a warning:
In file included from include/asm-generic/bug.h:13:0,
from [...]/arch/x86/include/asm/bug.h:38,
from include/linux/bug.h:4,
from include/drm/drm_mm.h:39,
from include/drm/drm_vma_manager.h:26,
from include/drm/ttm/ttm_bo_api.h:35,
from drivers/gpu/drm/radeon/radeon_ttm.c:32:
drivers/gpu/drm/radeon/radeon_ttm.c: In function 'radeon_ttm_gtt_read':
include/linux/kernel.h:712:17: warning: comparison of distinct pointer
types lacks a cast [enabled by default]
(void) (&_min1 == &_min2); \
^
drivers/gpu/drm/radeon/radeon_ttm.c:938:22: note: in expansion of macro
'min'
ssize_t cur_size = min(size, PAGE_SIZE - off);
^
Silence this warning by casting "PAGE_SIZE - off" to size_t. Since
"PAGE_SIZE - off" is between 0 and PAGE_SIZE, and PAGE_SIZE is at most
21 bits wide while size_t is at least 32 bits wide, this should be safe.
Signed-off-by: Paul Bolle
---
Compile tested only (on 32 and 64 bit x86).
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index 77f5b0c..5c87979 100644
--- a/drivers/gpu/drm/radeon/radeon_ttm.c
+++ b/drivers/gpu/drm/radeon/radeon_ttm.c
@@ -935,7 +935,7 @@ static ssize_t radeon_ttm_gtt_read(struct file *f, char
__user *buf,
while (size) {
loff_t p = *pos / PAGE_SIZE;
unsigned off = *pos & ~PAGE_MASK;
- ssize_t cur_size = min(size, PAGE_SIZE - off);
+ ssize_t cur_size = min(size, (size_t)(PAGE_SIZE - off));
struct page *page;
void *ptr;
--
1.8.5.3
[PATCH] drm/radeon: silence GCC warning on 32 bit
On Thu, 2014-02-20 at 16:07 -0500, Ilia Mirkin wrote:
> On Thu, Feb 20, 2014 at 4:02 PM, Paul Bolle wrote:
> > @@ -935,7 +935,7 @@ static ssize_t radeon_ttm_gtt_read(struct file *f, char
> > __user *buf,
> > while (size) {
> > loff_t p = *pos / PAGE_SIZE;
> > unsigned off = *pos & ~PAGE_MASK;
> > - ssize_t cur_size = min(size, PAGE_SIZE - off);
> > + ssize_t cur_size = min(size, (size_t)(PAGE_SIZE - off));
>
> Isn't the usual way of dealing with these to do something like
>
> ssize_t cur_size = min_t(ssize_t, size, PAGE_SIZE - off)
I wouldn't know. I did
$ git grep -n "(size_t)(PAGE_SIZE"
arch/powerpc/mm/dma-noncoherent.c:357: size_t seg_size =
min((size_t)(PAGE_SIZE - offset), size);
arch/tile/kernel/pci-dma.c:176: size_t bytes = min(size, (size_t)(PAGE_SIZE
- offset));
arch/tile/kernel/pci-dma.c:192: size_t bytes = min(size, (size_t)(PAGE_SIZE
- offset));
drivers/net/wireless/ti/wlcore/main.c:806: len = min(maxlen,
(size_t)(PAGE_SIZE - wl->fwlog_size));
drivers/scsi/libfc/fc_libfc.c:143:
(size_t)(PAGE_SIZE - (off & ~PAGE_MASK)));
drivers/target/tcm_fc/tfc_io.c:160: tlen = min(tlen,
(size_t)(PAGE_SIZE -
drivers/target/tcm_fc/tfc_io.c:311: tlen = min(tlen,
(size_t)(PAGE_SIZE -
and concluded my solution was acceptable. Is your alternative considered
to be better?
Paul Bolle
[PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver
On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote:
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> +config PWM_CRC
> + bool "Intel Crystalcove (CRC) PWM support"
> + depends on X86 && INTEL_SOC_PMIC
> + help
> + Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM
> + control.
> --- a/drivers/pwm/Makefile
> +++ b/drivers/pwm/Makefile
> +obj-$(CONFIG_PWM_CRC)+= pwm-crc.o
PWM_CRC is a bool symbol. So pwm-crc.o can never be part of a module.
(If I'm wrong, and that object file can actually be part of a module,
you can stop reading here.)
> --- /dev/null
> +++ b/drivers/pwm/pwm-crc.c
> +#include
Perhaps this include is not needed.
> +static const struct pwm_ops crc_pwm_ops = {
> + .config = crc_pwm_config,
> + .enable = crc_pwm_enable,
> + .disable = crc_pwm_disable,
> + .owner = THIS_MODULE,
For built-in only code THIS_MODULE is basically equivalent to NULL (see
include/linux/export.h). So I guess this line can be dropped.
> +};
> +static struct platform_driver crystalcove_pwm_driver = {
> + .probe = crystalcove_pwm_probe,
> + .remove = crystalcove_pwm_remove,
> + .driver = {
> + .name = "crystal_cove_pwm",
> + },
> +};
> +
> +module_platform_driver(crystalcove_pwm_driver);
Speaking from memory: for built-in only code this is equivalent to
calling
platform_driver_register(_pwm_driver);
from a wrapper, and marking that wrapper with device_initcall().
> +MODULE_AUTHOR("Shobhit Kumar ");
> +MODULE_DESCRIPTION("Intel Crystal Cove PWM Driver");
> +MODULE_LICENSE("GPL v2");
These macros will be effectively preprocessed away for built-in only
code.
Paul Bolle
[PATCH] radeon: add AGPMode 1 quirk for RV250
The Intel 82855PM host bridge / Mobility FireGL 9000 RV250 combination
in an (outdated) ThinkPad T41 needs AGPMode 1 for suspend/resume (under
KMS, that is). So add a quirk for it.
(Change R250 to RV250 in comment for preceding quirk too.)
Signed-off-by: Paul Bolle
---
0) Last tested on v3.6.7. The patch was cherry-picked on top of
v3.7-rc6.
1) A similar patch was submitted twenty months ago via
https://bugzilla.redhat.com/show_bug.cgi?id=531825 , but nothing
happened after that.
drivers/gpu/drm/radeon/radeon_agp.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_agp.c
b/drivers/gpu/drm/radeon/radeon_agp.c
index 10ea17a..4243334 100644
--- a/drivers/gpu/drm/radeon/radeon_agp.c
+++ b/drivers/gpu/drm/radeon/radeon_agp.c
@@ -69,9 +69,12 @@ static struct radeon_agpmode_quirk
radeon_agpmode_quirk_list[] = {
/* Intel 82830 830 Chipset Host Bridge / Mobility M6 LY Needs AGPMode 2
(fdo #17360)*/
{ PCI_VENDOR_ID_INTEL, 0x3575, PCI_VENDOR_ID_ATI, 0x4c59,
PCI_VENDOR_ID_DELL, 0x00e3, 2},
- /* Intel 82852/82855 host bridge / Mobility FireGL 9000 R250 Needs
AGPMode 1 (lp #296617) */
+ /* Intel 82852/82855 host bridge / Mobility FireGL 9000 RV250 Needs
AGPMode 1 (lp #296617) */
{ PCI_VENDOR_ID_INTEL, 0x3580, PCI_VENDOR_ID_ATI, 0x4c66,
PCI_VENDOR_ID_DELL, 0x0149, 1},
+ /* Intel 82855PM host bridge / Mobility FireGL 9000 RV250 Needs AGPMode
1 for suspend/resume */
+ { PCI_VENDOR_ID_INTEL, 0x3340, PCI_VENDOR_ID_ATI, 0x4c66,
+ PCI_VENDOR_ID_IBM, 0x0531, 1},
/* Intel 82852/82855 host bridge / Mobility 9600 M10 RV350 Needs
AGPMode 1 (deb #467460) */
{ PCI_VENDOR_ID_INTEL, 0x3580, PCI_VENDOR_ID_ATI, 0x4e50,
0x1025, 0x0061, 1},
--
1.7.7.6
[PATCH] drm/nv40/pm: silence GCC warnings
Building nv40_pm.o triggers these GCC warnings: drivers/gpu/drm/nouveau/nv40_pm.c: In function 'nv40_pm_clocks_pre': drivers/gpu/drm/nouveau/nv40_pm.c:164:41: warning: 'log2P' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/gpu/drm/nouveau/nv40_pm.c:165:38: warning: 'M2' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/gpu/drm/nouveau/nv40_pm.c:165:45: warning: 'M1' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/gpu/drm/nouveau/nv40_pm.c:165:25: warning: 'N2' may be used uninitialized in this function [-Wmaybe-uninitialized] drivers/gpu/drm/nouveau/nv40_pm.c:165:51: warning: 'N1' may be used uninitialized in this function [-Wmaybe-uninitialized] But these variables seem to be initialized when used there. If the preceding call of nv40_calc_pll() fails it will return a negative value and this code will never be run. And if that call succeeds it will return zero and all those five variables ought to be initialized when used there. Anyhow, it turns out that these warnings can be silenced by giving GCC slightly more detailed information a little earlier. See, get_pll_limits() returns an error-code integer (ie, negative on failure, zero on success). And a trivial tweak to nv40_calc_pll() that takes this into account makes these errors go away. Signed-off-by: Paul Bolle --- 0) I noticed these warnings while building recent releases (eg, v3.6-rc7, v3.6, and v3.6.1) on current Fedora 17, using Fedora's default config. But I found identical warnings in a build log for release v3.4-rc1. I didn't bother checking earlier releases. 1) Compile tested only (I do not have the hardware involved at hand). 2) This is not the only place where get_pll_limits()'s return value is checked. But this is apparently the only place where GCC needs to know that any non-zero return will be negative. drivers/gpu/drm/nouveau/nv40_pm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nv40_pm.c b/drivers/gpu/drm/nouveau/nv40_pm.c index e66273a..3df30cb 100644 --- a/drivers/gpu/drm/nouveau/nv40_pm.c +++ b/drivers/gpu/drm/nouveau/nv40_pm.c @@ -114,7 +114,7 @@ nv40_calc_pll(struct drm_device *dev, u32 reg, struct pll_lims *pll, int ret; ret = get_pll_limits(dev, reg, pll); - if (ret) + if (ret < 0) return ret; if (clk < pll->vco1.maxfreq) -- 1.7.11.4
[i915] WARNING: [...] drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector
On both v3.13-rc1 and v3.13-rc2 is see this at every boot and during every suspend and resume cycle: <4>[2.682468] WARNING: CPU: 0 PID: 173 at drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector+0x42/0x50 [i915]() <5>[2.682470] Modules linked in: i915(F+) ata_generic(F) pata_acpi(F) yenta_socket(F+) i2c_algo_bit(F) drm_kms_helper(F) tg3(F+) ptp(F) pps_core(F) drm(F) i2c_core(F) video(F) sunrpc(F) <5>[2.682489] CPU: 0 PID: 173 Comm: systemd-udevd Tainted: GF 3.13.0-0.rc2.1.local0.fc18.i686 #1 <5>[2.682492] Hardware name: IBM 2525FAG/2525FAG, BIOS 74ET61WW (2.06 ) 03/14/2006 <5>[2.682495] f54739f4 c09b66d2 f5473a24 c0449b14 c0b541a4 <5>[2.682502] 00ad f82c9524 26dc f8282692 f8282692 f555ed80 00061200 <5>[2.682509] f567c000 f5473a34 c0449b52 0009 f5473a40 f8282692 f5578800 <5>[2.682516] Call Trace: <5>[2.682528] [] dump_stack+0x41/0x52 <5>[2.682534] [] warn_slowpath_common+0x84/0xa0 <5>[2.682571] [] ? intel_get_pipe_from_connector+0x42/0x50 [i915] <5>[2.682607] [] ? intel_get_pipe_from_connector+0x42/0x50 [i915] <5>[2.682612] [] warn_slowpath_null+0x22/0x30 <5>[2.682648] [] intel_get_pipe_from_connector+0x42/0x50 [i915] <5>[2.682689] [] intel_panel_disable_backlight+0x21/0x160 [i915] <5>[2.682725] [] intel_disable_lvds+0x41/0x160 [i915] <5>[2.682760] [] i9xx_crtc_disable+0x200/0x2c0 [i915] <5>[2.682802] [] ? gen4_read32+0x31/0x90 [i915] <5>[2.682839] [] intel_modeset_setup_hw_state+0x92e/0xb00 [i915] <5>[2.682844] [] ? power_down+0x8c/0x8d <5>[2.682884] [] ? gen4_write64+0xa0/0xa0 [i915] <5>[2.682920] [] intel_modeset_gem_init+0x20/0x30 [i915] <5>[2.682950] [] i915_driver_load+0xb53/0xdd0 [i915] <5>[2.682978] [] ? i915_switcheroo_set_state+0xa0/0xa0 [i915] <5>[2.683003] [] drm_dev_register+0x8c/0x1a0 [drm] <5>[2.683043] [] drm_get_pci_dev+0x85/0x130 [drm] <5>[2.683050] [] ? sysfs_do_create_link_sd.isra.3+0xa8/0x1c0 <5>[2.683057] [] ? notifier_call_chain+0x43/0x60 <5>[2.683086] [] i915_pci_probe+0x3a/0x80 [i915] <5>[2.683093] [] pci_device_probe+0x79/0xc0 <5>[2.683097] [] ? sysfs_create_link+0x25/0x40 <5>[2.683104] [] driver_probe_device+0x79/0x360 <5>[2.683108] [] ? pci_match_device+0x9e/0xb0 <5>[2.683113] [] __driver_attach+0x91/0xa0 <5>[2.683117] [] ? driver_probe_device+0x360/0x360 <5>[2.683121] [] bus_for_each_dev+0x42/0x80 <5>[2.683125] [] driver_attach+0x1e/0x20 <5>[2.683130] [] ? driver_probe_device+0x360/0x360 <5>[2.683134] [] bus_add_driver+0xec/0x210 <5>[2.683138] [] driver_register+0x59/0xe0 <5>[2.683142] [] ? 0xf7fb1fff <5>[2.683147] [] __pci_register_driver+0x33/0x40 <5>[2.683150] [] ? 0xf7fb1fff <5>[2.683166] [] drm_pci_init+0xfd/0x110 [drm] <5>[2.683170] [] ? 0xf7fb1fff <5>[2.683198] [] i915_init+0x5e/0x60 [i915] <5>[2.683203] [] do_one_initcall+0xda/0x1a0 <5>[2.683206] [] ? 0xf7fb1fff <5>[2.683211] [] ? __add_event_to_tracers+0x21/0x30 <5>[2.683215] [] ? 0xf7fb1fff <5>[2.683221] [] ? set_memory_ro+0x37/0x40 <5>[2.683228] [] load_module+0x1abd/0x2390 <5>[2.683235] [] SyS_init_module+0xa7/0x110 <5>[2.683242] [] ? vm_mmap_pgoff+0x8b/0xb0 <5>[2.683248] [] sysenter_do_call+0x12/0x28 Feel free to prod for further details. Paul Bolle
[i915] WARNING: [...] drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector
On Sun, 2013-12-01 at 10:58 +0100, Daniel Vetter wrote: > Should be fixed with > > commit 7c063c725987406d743cc7de7625ff224fab75de > Author: Jesse Barnes > Date: Tue Nov 26 09:13:41 2013 -0800 > > drm/i915: take mode config lock around crtc disable at suspend > > which is currently in drm-intel-fixes. I'll forward it early next week. Thanks! The WARNING is now gone during suspend and resume (having tested that thoroughly - ie, twice). But I still see it at boot. Is there a related fix for that WARNING during boot? Paul Bolle
[i915] WARNING: [...] drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector
On Mon, 2013-12-02 at 08:33 +0100, Daniel Vetter wrote: > On Sun, Dec 1, 2013 at 5:57 PM, Paul Bolle wrote: > > The WARNING is now gone during suspend and resume (having tested that > > thoroughly - ie, twice). But I still see it at boot. Is there a related > > fix for that WARNING during boot? > > Hm, I've never seen it during boot. Can you please boot with > drm.debug=0xe and attach the dmesg with the WARN? Sure. This generated quite a bit of debug messages so I only copied the WARNING and the drm (related) messages immediately preceding it. Please feel free to prod again if that's insufficient. [...] <6>[2.727041] [drm] GMBUS [i915 gmbus panel] timed out, falling back to bit banging on pin 3 <7>[2.729161] [drm:drm_do_probe_ddc_edid], drm: skipping non-existent adapter i915 gmbus panel <7>[2.729166] [drm:intel_lvds_init], using mode from VBT: <7>[2.729170] [drm:drm_mode_debug_printmodeline], <5>[2.729175] Modeline 0:"1024x768" 0 54160 1024 1048 1184 1344 768 771 777 806 0x8 0xa <7>[2.729464] [drm:intel_lvds_init], detected single-link lvds configuration <7>[2.729575] [drm:intel_panel_get_backlight], get backlight PWM = 13875 <7>[2.729579] [drm:intel_panel_get_max_backlight], max backlight PWM = 13875 <7>[2.729732] [drm:i915_gem_setup_global_gtt], clearing unused GTT space: [0, 000] <7>[2.733459] [drm:i915_gem_object_create_stolen], creating stolen object: size=2 <7>[2.733466] [drm:i915_pages_create_for_stolen], offset=0x0, size=131072 <7>[2.733514] [drm:i915_gem_context_init], Disabling HW Contexts; old hardware <6>[2.733649] [drm] initialized overlay support <7>[2.733654] [drm:intel_modeset_readout_hw_state], [CRTC:3] hw state readout: disabled <7>[2.733664] [drm:intel_modeset_readout_hw_state], [CRTC:4] hw state readout: enabled <7>[2.733670] [drm:intel_modeset_readout_hw_state], [ENCODER:6:LVDS-6] hw state readout: enabled, pipe B <7>[2.733674] [drm:intel_modeset_readout_hw_state], [ENCODER:10:DAC-10] hw state readout: disabled, pipe A <7>[2.733679] [drm:intel_modeset_readout_hw_state], [ENCODER:12:TV-12] hw state readout: disabled, pipe A <7>[2.733683] [drm:intel_modeset_readout_hw_state], [CONNECTOR:5:LVDS-1] hw state readout: enabled <7>[2.733687] [drm:intel_modeset_readout_hw_state], [CONNECTOR:9:VGA-1] hw state readout: disabled <7>[2.733690] [drm:intel_modeset_readout_hw_state], [CONNECTOR:11:SVIDEO-1] hw state readout: disabled <7>[2.733696] [drm:intel_dump_pipe_config], [CRTC:3][setup_hw_state] config for pipe A <7>[2.733699] [drm:intel_dump_pipe_config], cpu_transcoder: A <7>[2.733702] [drm:intel_dump_pipe_config], pipe bpp: 0, dithering: 0 <7>[2.733705] [drm:intel_dump_pipe_config], fdi/pch: 0, lanes: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 <7>[2.733708] [drm:intel_dump_pipe_config], dp: 0, gmch_m: 0, gmch_n: 0, link_m: 0, link_n: 0, tu: 0 <7>[2.733712] [drm:intel_dump_pipe_config], requested mode: <7>[2.733714] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0 <7>[2.733719] [drm:intel_dump_pipe_config], adjusted mode: <7>[2.733721] [drm:drm_mode_debug_printmodeline], Modeline 0:"" 0 0 0 0 0 0 0 0 0 0 0x0 0x0 <7>[2.733726] [drm:intel_dump_crtc_timings], crtc timings: 0 0 0 0 0 0 0 0 0, type: 0x0 flags: 0x0 <7>[2.733730] [drm:intel_dump_pipe_config], port clock: 0 <7>[2.733732] [drm:intel_dump_pipe_config], pipe src size: 0x0 <7>[2.733735] [drm:intel_dump_pipe_config], gmch pfit: control: 0x, ratios: 0x, lvds border: 0x <7>[2.733738] [drm:intel_dump_pipe_config], pch pfit: pos: 0x, size: 0x, disabled <7>[2.733741] [drm:intel_dump_pipe_config], ips: 0 <7>[2.733743] [drm:intel_dump_pipe_config], double wide: 0 <7>[2.733747] [drm:intel_sanitize_crtc], [CRTC:4] wrong plane connection detected! <4>[2.733750] [ cut here ] <4>[2.733815] WARNING: CPU: 0 PID: 173 at drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector+0x42/0x50 [i915]() <5>[2.733818] Modules linked in: i915(F+) ata_generic(F) pata_acpi(F) i2c_algo_bit(F) drm_kms_helper(F) yenta_socket(F+) drm(F) tg3(F) ptp(F) pps_core(F) i2c_core(F) video(F) sunrpc(F) <5>[2.733836] CPU: 0 PID: 173 Comm: systemd-udevd Tainted: GF 3.13.0-0.rc2.1.local1.fc18.i686 #1 <5>[2.733839] Hardware name: IBM 2525FAG/2525FAG, BIOS 74ET61WW (2.06 ) 03/14/2006 <5>[2.733842] f54979f4 c09b66d2 f5497a24 c0449b14 c0b541a4 <5>[2.733850] 00ad f82d35
[PATCH] drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
On Mon, 2013-12-02 at 11:08 +0200, ville.syrjala at linux.intel.com wrote:
> From: Ville Syrj?l?
>
> Some lower level things get angry if we don't have modeset locks
> during intel_modeset_setup_hw_state(). Actually the resume and
> lid_notify codepaths alreday hold the locks, but the init codepath
> doesn't, so fix that.
>
> Signed-off-by: Ville Syrj?l?
> ---
> Totally untested, but looks correct to me.
I assume I need to test this, on top of 7c063c725987 ("drm/i915: take
mode config lock around crtc disable at suspend"), to see if this makes
the WARNING that I currently see at boot go away?
Paul Bolle
> drivers/gpu/drm/i915/intel_display.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 080f6fd..114db51 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11046,7 +11046,9 @@ void intel_modeset_gem_init(struct drm_device *dev)
>
> intel_setup_overlay(dev);
>
> + drm_modeset_lock_all(dev);
> intel_modeset_setup_hw_state(dev, false);
> + drm_modeset_unlock_all(dev);
> }
>
> void intel_modeset_cleanup(struct drm_device *dev)
[PATCH] drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
On Mon, 2013-12-02 at 14:12 +0200, Ville Syrj?l? wrote:
> On Mon, Dec 02, 2013 at 11:00:29AM +0100, Paul Bolle wrote:
> > I assume I need to test this, on top of 7c063c725987 ("drm/i915: take
> > mode config lock around crtc disable at suspend"), to see if this makes
> > the WARNING that I currently see at boot go away?
>
> Yeah that would be nice.
A grand total of one boot suggests that this patch really makes the
v3.13+ WARNING go away at boot too. Should I test more thoroughly?
Paul Bolle
[i915] WARNING: [...] drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector
On Mon, 2013-12-02 at 15:23 +0100, Daniel Vetter wrote: > On Mon, Dec 2, 2013 at 10:53 AM, Paul Bolle wrote: > > This generated quite a bit of debug messages so I only copied the > > WARNING and the drm (related) messages immediately preceding it. Please > > feel free to prod again if that's insufficient. > > Yeah, the beginning of the drm message would are wanted since I need > to know what exactly your hardware claims to support ;-) > > But the backtrace confirms my first hunch for now ... Just want to > confirm before sending out a patch with commit message. It seems Ville's patch ( https://lkml.org/lkml/2013/12/2/77 ) does the trick. Do you still need the additional info? Paul Bolle
[i915] WARNING: [...] drivers/gpu/drm/i915/intel_display.c:9948 intel_get_pipe_from_connector
On Tue, 2013-12-03 at 16:19 +0100, Daniel Vetter wrote: > I'd like to confirm the actual cause (I suspect that we switch > pipes around) for why you see this but other machines don't show > this to augment the commit message. But I've merged the fix already. The dmesg, up to and including the WARNING, is attached. Have fun! Paul Bolle <6>[0.00] Initializing cgroup subsys cpuset <6>[0.00] Initializing cgroup subsys cpu <6>[0.00] Initializing cgroup subsys cpuacct <5>[0.00] Linux version 3.13.0-0.rc2.1.local1.fc18.i686 ([...]) (gcc version 4.7.2 20121109 (Red Hat 4.7.2-8) (GCC) ) #1 SMP Sun Dec 1 11:58:49 CET 2013 <6>[0.00] Disabled fast string operations <6>[0.00] e820: BIOS-provided physical RAM map: <6>[0.00] BIOS-e820: [mem 0x-0x0009efff] usable <6>[0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved <6>[0.00] BIOS-e820: [mem 0x000d-0x000d3fff] reserved <6>[0.00] BIOS-e820: [mem 0x000dc000-0x000f] reserved <6>[0.00] BIOS-e820: [mem 0x0010-0x7f6d] usable <6>[0.00] BIOS-e820: [mem 0x7f6e-0x7f6f4fff] ACPI data <6>[0.00] BIOS-e820: [mem 0x7f6f5000-0x7f6f] ACPI NVS <6>[0.00] BIOS-e820: [mem 0x7f70-0x7fff] reserved <6>[0.00] BIOS-e820: [mem 0xe000-0xefff] reserved <6>[0.00] BIOS-e820: [mem 0xf0008000-0xf000bfff] reserved <6>[0.00] BIOS-e820: [mem 0xfec0-0xfec0] reserved <6>[0.00] BIOS-e820: [mem 0xfed14000-0xfed19fff] reserved <6>[0.00] BIOS-e820: [mem 0xfed2-0xfed8] reserved <6>[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved <6>[0.00] BIOS-e820: [mem 0xff00-0x] reserved <5>[0.00] Notice: NX (Execute Disable) protection cannot be enabled: non-PAE kernel! <6>[0.00] SMBIOS 2.3 present. <7>[0.00] DMI: IBM 2525FAG/2525FAG, BIOS 74ET61WW (2.06 ) 03/14/2006 <7>[0.00] e820: update [mem 0x-0x0fff] usable ==> reserved <7>[0.00] e820: remove [mem 0x000a-0x000f] usable <6>[0.00] e820: last_pfn = 0x7f6e0 max_arch_pfn = 0x10 <7>[0.00] MTRR default type: uncachable <7>[0.00] MTRR fixed ranges enabled: <7>[0.00] 0-9 write-back <7>[0.00] A-B uncachable <7>[0.00] C-C write-protect <7>[0.00] D-DBFFF uncachable <7>[0.00] DC000-D write-back <7>[0.00] E-F write-protect <7>[0.00] MTRR variable ranges enabled: <7>[0.00] 0 base 0 mask F8000 write-back <7>[0.00] 1 base 07F70 mask 0 uncachable <7>[0.00] 2 base 07F80 mask FFF80 uncachable <7>[0.00] 3 disabled <7>[0.00] 4 disabled <7>[0.00] 5 disabled <7>[0.00] 6 disabled <7>[0.00] 7 disabled <6>[0.00] PAT not supported by CPU. <7>[0.00] initial memory mapped: [mem 0x-0x013f] <7>[0.00] Base memory trampoline at [c009b000] 9b000 size 16384 <6>[0.00] init_memory_mapping: [mem 0x-0x000f] <7>[0.00] [mem 0x-0x000f] page 4k <6>[0.00] init_memory_mapping: [mem 0x36c0-0x36ff] <7>[0.00] [mem 0x36c0-0x36ff] page 2M <6>[0.00] init_memory_mapping: [mem 0x3000-0x36bf] <7>[0.00] [mem 0x3000-0x36bf] page 2M <6>[0.00] init_memory_mapping: [mem 0x0010-0x2fff] <7>[0.00] [mem 0x0010-0x003f] page 4k <7>[0.00] [mem 0x0040-0x2fff] page 2M <6>[0.00] init_memory_mapping: [mem 0x3700-0x373fdfff] <7>[0.00] [mem 0x3700-0x373fdfff] page 4k <7>[0.00] BRK [0x00e6d000, 0x00e6dfff] PGTABLE <7>[0.00] BRK [0x00e6e000, 0x00e6] PGTABLE <6>[0.00] RAMDISK: [mem 0x33f7c000-0x35fb5fff] <5>[0.00] ACPI: RSDP 000f6c00 24 (v02 IBM ) <5>[0.00] ACPI: XSDT 7f6e4770 5C (v01 IBMTP-742060 LTP ) <5>[0.00] ACPI: FACP 7f6e4800 F4 (v03 IBMTP-742060 IBM 0001) <5>[0.00] ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 (20131115/tbfadt-572) <5>[0.00] ACPI BIOS Warning (bug): O
[PATCH] drm/omap: change "!CONFIG_FB_OMAP2" to "!FB_OMAP2"
On Wed, 2013-03-13 at 20:48 +0100, Paul Bolle wrote: > Signed-off-by: Paul Bolle > --- > Untested. Perhaps the first test that people with access to the relevant > hardware might do, is to test _before applying this patch_ with FB_OMAP2 > set. Perhaps this negative dependency isn't needed at all. Or is it > obvious? > > drivers/gpu/drm/omapdrm/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) This patch was sent exactly three months ago, shortly after v3.9-rc2 was released. This obvious typo is still present in v3.10-rc5. I didn't received any feedback on this patch. Did anyone had a look at it? Is it perhaps queued somewhere? Paul Bolle > diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig > index 09f65dc..45875a0 100644 > --- a/drivers/gpu/drm/omapdrm/Kconfig > +++ b/drivers/gpu/drm/omapdrm/Kconfig > @@ -1,7 +1,7 @@ > > config DRM_OMAP > tristate "OMAP DRM" > - depends on DRM && !CONFIG_FB_OMAP2 > + depends on DRM && !FB_OMAP2 > depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM > depends on OMAP2_DSS > select DRM_KMS_HELPER
[PATCH] drm/tegra: Include linux/types.h
"make headers_check" complains about include/uapi/drm/tegra_drm.h:
[...]/usr/include/drm/tegra_drm.h:21: found __[us]{8,16,32,64} type without
#include
So let's include linux/types.h in this header.
Signed-off-by: Paul Bolle
---
Tested only with "make headers_check". I don't actually build or run
code that uses tegra_drm.h.
include/uapi/drm/tegra_drm.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/drm/tegra_drm.h b/include/uapi/drm/tegra_drm.h
index 6e132a2..6698e81 100644
--- a/include/uapi/drm/tegra_drm.h
+++ b/include/uapi/drm/tegra_drm.h
@@ -17,6 +17,8 @@
#ifndef _UAPI_TEGRA_DRM_H_
#define _UAPI_TEGRA_DRM_H_
+#include
+
struct drm_tegra_gem_create {
__u64 size;
__u32 flags;
--
1.8.1.4
[PATCH] drm/tegra: Include linux/types.h
On Mon, 2013-06-17 at 22:33 +0200, Thierry Reding wrote: > That has already been fixed in linux-next. This header was added in v3.10-rc1. The fix in linux-next will ship in v3.11. Isn't that fix appropriate for (one of) the upcoming v3.10 release candidate(s)? Thanks, Paul Bolle
[PATCH] drm/tegra: drop "select DRM_HDMI"
Commit ac24c2204a76e5b42aa103bf963ae0eda1b827f3 ("drm/tegra: Use generic
HDMI infoframe helpers") added "select DRM_HDMI" to the DRM_TEGRA
Kconfig entry. But there is no Kconfig symbol named DRM_HDMI. The select
statement for that symbol is a nop. Drop it.
What was needed to use HDMI functionality was to select HDMI (which this
entry already did through depending on DRM) and to include linux/hdmi.h
(which this commit also did).
Signed-off-by: Paul Bolle
---
Untested.
drivers/gpu/drm/tegra/Kconfig | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/tegra/Kconfig b/drivers/gpu/drm/tegra/Kconfig
index c92955d..be1daf7 100644
--- a/drivers/gpu/drm/tegra/Kconfig
+++ b/drivers/gpu/drm/tegra/Kconfig
@@ -4,7 +4,6 @@ config DRM_TEGRA
select DRM_KMS_HELPER
select DRM_GEM_CMA_HELPER
select DRM_KMS_CMA_HELPER
- select DRM_HDMI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
--
1.7.11.7
[PATCH] drm/omap: change "!CONFIG_FB_OMAP2" to "!FB_OMAP2"
Signed-off-by: Paul Bolle --- Untested. Perhaps the first test that people with access to the relevant hardware might do, is to test _before applying this patch_ with FB_OMAP2 set. Perhaps this negative dependency isn't needed at all. Or is it obvious? drivers/gpu/drm/omapdrm/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/Kconfig b/drivers/gpu/drm/omapdrm/Kconfig index 09f65dc..45875a0 100644 --- a/drivers/gpu/drm/omapdrm/Kconfig +++ b/drivers/gpu/drm/omapdrm/Kconfig @@ -1,7 +1,7 @@ config DRM_OMAP tristate "OMAP DRM" - depends on DRM && !CONFIG_FB_OMAP2 + depends on DRM && !FB_OMAP2 depends on ARCH_OMAP2PLUS || ARCH_MULTIPLATFORM depends on OMAP2_DSS select DRM_KMS_HELPER -- 1.7.11.7
[BISECTED REGRESSION in 3.19-rc1] [drm/i915] WARNING: drivers/gpu/drm/drm_irq.c:1077 drm_wait_one_vblank
Andrey Skvortsov schreef op zo 01-02-2015 om 00:16 [+0300]:
> this warning exist in v3.19-rc6 and does not in v3.18. Bisection
> points to the commit 51e31d49c890552 "drm/i915: Use generic vblank wait".
> I have two machines with integrated Intel graphics and the problem
> happens only on the old one with GM965 chipset and X3100 integrated graphics.
I see this too, since v3.19-rc1, on an (outdated) ThinkPad X41.
> backtrace information:
>
> [ 31.780813] WARNING: CPU: 0 PID: 718 at drivers/gpu/drm/drm_irq.c:1077
> drm_wait_one_vblank+0x33/0x141 [drm]()
But it also prints
vblank not available on crtc 0, ret=-22
after the WARNING line, on that machine.
> [ 31.780815] Modules linked in: ecb(E) i915(E+) snd_hda_codec_generic(E)
> coretemp(E) btusb(E) kvm_intel(E) snd_hda_intel(E) snd_hda_controller(E)
> kvm(E) drm_kms_helper(E) snd_hda_code
> c(E) snd_pcsp(E) bluetooth(E) snd_hwdep(E) drm(E) lpc_ich(E) evdev(E)
> mfd_core(E) snd_pcm(E) snd_timer(E) snd(E) psmouse(E) serio_raw(E)
> i2c_algo_bit(E) i2c_i801(E) rfkill(E) soundcore(
>
>
> E) battery(E) button(E) video(E) ac(E)
> i2ccore(E) acpi_cpufreq(E) processor(E) fuse(E) parport_pc(E) ppdev(E) lp(E)
> parport(E) autofs4(E) ext4(E) crc16(E) jbd2(E) mbcache(E) sd_mod(E) a
> ta_generic(E) ahci(E) libahci(E) sdhci_pci(E) sdhci(E) firewire_ohci(E)
> b44(E) mii(E) ssb(E) ata_piix(E) firewire_core(E) crc_itu_t(E) mmc_core(E)
> libphy(E) libata(E) scsi_mod(E) xhci_h
> cd(E) ehci_pci(E) uhci_hcd(E) ehci_hcd(E) usbcore(E) usb_common(E) thermal(E)
> [ 31.780862] thermal_sys(E)
> [ 31.780866] CPU: 0 PID: 718 Comm: kworker/u4:3 Tainted: GE
> 3.17.0-rc5-150116--00578-g51e31d4 #16
> [ 31.780868] Hardware name: Dell Inc. Vostro 1500
> /0NX907, BIOS A06 04/21/2008
> [ 31.780873] Workqueue: events_unbound async_run_entry_fn
> [ 31.780875] a0544b9d 813d4e81
>
> [ 31.780879] 8103dec3 8800d84e0068 a0521c73
> 00070008
> [ 31.780882] 8800d84e 8801973e0800
> 6014
> [ 31.780886] Call Trace:
> [ 31.780890] [] ? dump_stack+0x4a/0x75
> [ 31.780894] [] ? warn_slowpath_common+0x7e/0x97
> [ 31.781050] [] ? drm_wait_one_vblank+0x33/0x141 [drm]
> [ 31.781078] [] ? drm_wait_one_vblank+0x33/0x141 [drm]
> [ 31.781122] [] ? intel_enable_tv+0x22/0x58 [i915]
> [ 31.781153] [] ? i9xx_crtc_enable+0x33b/0x397 [i915]
> [ 31.781184] [] ? __intel_set_mode+0x1160/0x1209 [i915]
> [ 31.781216] [] ? intel_set_mode+0x12/0x2c [i915]
> [ 31.781247] [] ? intel_get_load_detect_pipe+0x367/0x408
> [i915]
> [ 31.781281] [] ? intel_tv_detect+0x103/0x444 [i915]
> [ 31.781289] [] ?
> drm_helper_probe_single_connector_modes_merge_bits+0xc0/0x327 [drm_kms_helper]
> [ 31.781296] [] ?
> drm_fb_helper_probe_connector_modes+0x3d/0x51 [drm_kms_helper]
> [ 31.781303] [] ?
> drm_fb_helper_initial_config+0x3d/0x303 [drm_kms_helper]
> [ 31.781306] [] ? async_run_entry_fn+0x5a/0x110
> [ 31.781310] [] ? process_one_work+0x194/0x292
> [ 31.781313] [] ? worker_thread+0x236/0x298
> [ 31.781316] [] ? process_scheduled_works+0x2a/0x2a
> [ 31.781319] [] ? kthread+0x9e/0xa6
> [ 31.781322] [] ? kthread_freezable_should_stop+0x36/0x36
> [ 31.781326] [] ? ret_from_fork+0x7c/0xb0
> [ 31.781329] [] ? kthread_freezable_should_stop+0x36/0x36
> [ 31.782726] ---[ end trace e2b78017f1a10054 ]---
>
>
> lspci:
>
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile
> GM965/GL960 Integrated Graphics Controller (primary) [8086:2a02] (rev 0c)
> 00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960
> Integrated Graphics Controller (secondary) [8086:2a03] (rev 0c)
A naive revert, on top of v3.19-rc7, of commit 51e31d49c890552
("drm/i915: Use generic vblank wait") clashes with later changes. It
seems intel_wait_for_vblank() became an one line inline function in a
later commit.
Anyhow, is a fix for this queued somewhere?
Thanks,
Paul Bolle
4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?
On Wed, 2015-06-17 at 15:21 +0200, Pavel Machek wrote:
> On Wed 2015-06-17 15:07:41, Christian König wrote:
> > On 17.06.2015 14:49, Pavel Machek wrote:
> > >On Wed 2015-06-17 14:43:47, Pavel Machek wrote:
> > >>Hi!
> > >>
> > >>Video is broken on thinkpad T40p after resume from suspend. (In X
> > >>only, text console still works.)
> > >>
> > >>Maybe this is related?
> > >>
> > >>[ 5430.193071] radeon :01:00.0: putting AGP V2 device into 4x mode
> > >>[ 5430.193107] radeon :01:00.0: GTT: 256M 0xD000 - 0xDFFF
> > >>[ 5430.214670] radeon :01:00.0: WB disabled
> > >>[ 5430.214675] radeon :01:00.0: fence driver on ring 0 use gpu addr
> > >>0xd000 and cpu addr 0xf841a000
> > >>[ 5430.214721] [drm] radeon: ring at 0xD0001000
> > >>[ 5430.370867] [drm:r100_ring_test] *ERROR* radeon: ring test failed
> > >>(scratch(0x15E8)=0xCAFEDEAD)
> > >>[ 5430.370869] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
> > >>[ 5430.370872] radeon :01:00.0: failed initializing CP (-22).
> > >>
> > >>Hibernation works well here, including X. (Which has small glitch with
> > >>mouse cursor being corrupted until it is changed by application).
> > >>
> > >3.16.0-4-686-pae Debian 3.16.7-cktt11-1 kernel seems to have same
> > >problem, with same scratch(0x15E8)=0xCAFEDEAD message... so this is
> > >not "new" problem...
> > >
>
> > Looks like CP init doesn't work. Well is there any kernel where that did
> > worked?
>
> Unfortunately, not as far as I know.
>
> > If yes it might be a good idea to bisect to narrow down the problem.
>
> No such luck. I may try something like "3.0" if we are really
> desperate (2.6.X kernels probably won't won't boot with recent
> userland), but I suspect it just never worked.
The above looks very much like the issue that made me write commit
45171002b01b ("radeon: add AGPMode 1 quirk for RV250"). See
https://bugzilla.redhat.com/show_bug.cgi?id=531825 for a lot of
background.
Does booting with radeon.agpmode=1 survive a suspend and resume cycle?
Hope this helps,
Paul Bolle
4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?
On Wed, 2015-06-17 at 16:10 +0200, Pavel Machek wrote:
> > The above looks very much like the issue that made me write commit
> > 45171002b01b ("radeon: add AGPMode 1 quirk for RV250"). See
> > https://bugzilla.redhat.com/show_bug.cgi?id=531825 for a lot of
> > background.
> >
> > Does booting with radeon.agpmode=1 survive a suspend and resume cycle?
>
> Yes, that option helps. Thanks!
Then I suggest you add another quirk for your T40p (after testing
agpmode 2 also). Because this all seems to be caused by a broken BIOS,
and/or broken AGP thingy, and/or broken RV250 (or the interaction of
these things or whatever). Maddening stuff, impossible to debug.
Good luck,
Paul Bolle
[Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver
Hi Shobhit, On Thu, 2015-06-18 at 23:24 +0530, Shobhit Kumar wrote: > On Fri, May 1, 2015 at 2:42 AM, Paul Bolle wrote: > > On Wed, 2015-04-29 at 19:30 +0530, Shobhit Kumar wrote: > >> --- a/drivers/pwm/Kconfig > >> +++ b/drivers/pwm/Kconfig > > > >> +config PWM_CRC > >> + bool "Intel Crystalcove (CRC) PWM support" > >> + depends on X86 && INTEL_SOC_PMIC > >> + help > >> + Generic PWM framework driver for Crystalcove (CRC) PMIC based PWM > >> + control. > > > >> --- a/drivers/pwm/Makefile > >> +++ b/drivers/pwm/Makefile > > > >> +obj-$(CONFIG_PWM_CRC)+= pwm-crc.o > > > > PWM_CRC is a bool symbol. So pwm-crc.o can never be part of a module. > > I actually started this as a module but later decided to make it as > bool because INTEL_SOC_PMIC on which this depends is itself a bool as > well. As does GPIO_CRYSTAL_COVE and that's a tristate. So? > Still it is good to keep the module based initialization. > Firstly because it causes no harm If I got a dime for every time people used an argument like that I ... I could treat myself to an ice cream. A really big ice cream. Hmm, that doesn't sound too impressive. But still, "causes no harm" is below the bar for kernel code. Kernel code needs to add value. > and even though some of the macros > are pre-processed out, gives info about the driver. None of which can't be gotten elsewhere (ie, the commit message, or the file these macro reside in). > Secondly there > were discussion on why INTEL_SOC_PMIC is bool (note this driver also > has module based initialization even when bool). Yes, there's copy and paste going on even in kernel development. > I am guessing because > of some tricky module load order dependencies. If ever that becomes a > module, this can mostly be unchanged to be loaded as a module. You put in a macro, or any other bit of code, when it's needed, not beforehand, "just in case". That's silly. Thanks, Paul Bolle
[PATCH] drm/i915: enable BIOS hang workaround for Lenovo T60 too
On Fri, 2015-06-19 at 17:44 +0200, Daniel Vetter wrote: > I wonder whether we shouldn't do this unconditionally for gen4 and earlier > for Lenovo ... Anyway this needs Cc: stable at vger.kernel.org and is for > Jani to pick up. > > Thanks for figuring out what's been broken here. > -Daniel > > > pci_set_power_state(drm_dev->pdev, PCI_D3hot); > > > > return 0; Just two days ago we discussed this bug too, see https://lkml.org/lkml/2015/6/17/327 . That message contains a link to a patch I cobbled together for yet another ThinkPad hitting this, but with PCI_SUBVENDOR_ID_IBM involved. Paul Bolle
[Intel-gfx] [PATCH 6/8] drivers/pwm: Add Crystalcove (CRC) PWM driver
[Added Paul Gortmaker.] Hi Shobhit, On Fri, 2015-06-19 at 12:16 +0530, Shobhit Kumar wrote: > So what is the exact big problem with this ? The main problem I have is that it's hard to read a submitter's mind. And, I think, in cases like this we need to know if the submitter just made some silly mistake or that the mismatch (between Kconfig type and code) was intentional. So each time such a mismatch is spotted the submitter ought to be asked about it. (I'd guess that one or two new drivers are submitted _each_ day. And these mismatches are quite common. I'd say I receive answers like: - "Oops, yes bool should have been tristate"; or - "Oops, forgot to clean up after noticing tristate didn't work"; or - "I just copy-and-pasted a similar driver, the module stuff isn't actually needed" at least once a week. Not sure, I don't keep track of this stuff.) Furthermore, it appears that Paul Gortmaker is on a mission to, badly summarized, untangle the module and init code. See for instance https://lkml.org/lkml/2015/5/28/809 and https://lkml.org/lkml/2015/5/31/205 . Now, I don't know whether (other) Paul is bothered by these MODULE_* macros. But Paul did submit a series that adds builtin_platform_driver(), see https://lkml.org/lkml/2015/5/10/131 . That new macro ensures built-in only code doesn't have to use module_platform_driver(), which your patch also uses. So perhaps Paul can explain some of the non-obvious issues caused by built-in only code using module specific constructs. > I can anyway shove out these macros to end the discussion. I'd rather convince you than annoy you into doing as I suggested. > BTW whether you buy the argument or not, please do treat yourself > with ice cream for being able to make such a comment. Will do. Thanks, Paul Bolle
[PATCH v5 4/6] drm: bridge/dw_hdmi-i2s-audio: add audio driver
Something I didn't notice in v4, sorry. On Sat, 2015-06-20 at 00:28 +0800, Yakir Yang wrote: > --- /dev/null > +++ b/drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c > +#define DRIVER_NAME "dw-hdmi-i2s-audio" > +MODULE_ALIAS(PLATFORM_MODULE_PREFIX DRIVER_NAME); 0) Side note: this is the first time that PLATFORM_MODULE_PREFIX is used inside MODULE_ALIAS(). But none of the 1000+ other "platform:" aliases do that. And neither does 5/6 of this series! That suggests, I think, that this shouldn't be done. You could consider adding something like #define MODULE_ALIAS_PLATFORM(NAME) MODULE_ALIAS(PLATFORM_MODULE_PREFIX NAME) But then, I think, all the current 1000+ platform: aliases should be converted to that macro. Would that be worth it? 1) Now on to my remark: this alias seems to be only useful if there also is a struct platform_device with a "dw-hdmi-i2s-audio" name. Because that platform_device would, badly summarized, fire of a "MODALIAS=platform:dw-hdmi-i2s-audio" uevent when created. Which, in its turn, would trigger userspace to load this module, correct? But I think there's no platform_device with a "dw-hdmi-i2s-audio" name. So I wonder whether this MODULE_ALIAS() is actually needed. What breaks if you leave it out? (Likewise for 5/6, but there the platform_device should have a "rockchip-hdmi-audio" name.) Thanks, Paul Bolle
[git pull] drm fixes
On Sat, 2015-02-28 at 22:08 -0800, Linus Torvalds wrote:
> Hmm. 3.19 works fine, even if it ends up spewing
>
> WARNING: CPU: 0 PID: 6 at drivers/gpu/drm/drm_irq.c:1121
> drm_wait_one_vblank+0x125/0x130()
> vblank not available on crtc 1, ret=-22
>
> a lot.
For what it's worth, that stream of WARNINGs was reported for v3.19-rc1
in http://lkml.kernel.org/r/20150131211609.GA3710 at yulia-desktop .
Commit f9b61ff6bce9 ("drm/i915: Push vblank enable/disable past
encoder->enable/disable") silenced it again in v4.0-rc1. I guess that
commit will end up in v3.19-stable in due time.
Paul Bolle
[PATCH v4 14/15] ASoC: rockchip/rockchip-hdmi-audio: add sound driver for hdmi audio
On Sat, 2015-02-28 at 22:04 -0500, Yakir Yang wrote:
> --- /dev/null
> +++ b/sound/soc/rockchip/rockchip_hdmi_audio.c
> @@ -0,0 +1,169 @@
> +/*
> + * rockchip-hdmi-card.c
Doesn't match the filename. Is this line needed anyway?
> + *
> + * ROCKCHIP ALSA SoC DAI driver for HDMI audio on rockchip processors.
> + * Copyright (c) 2014, ROCKCHIP CORPORATION. All rights reserved.
> + * Authors: Yakir Yang
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.*
> + *
> + */
This states the license is plain GPL v2.
> +MODULE_LICENSE("GPL");
So you probably want
MODULE_LICENSE("GPL v2");
here.
Paul Bolle
[PATCH v4 13/15] ASoC: codec/dw-hdmi-audio: add codec driver for dw hdmi audio
On Sat, 2015-02-28 at 21:59 -0500, Yakir Yang wrote:
> --- /dev/null
> +++ b/sound/soc/codecs/dw-hdmi-audio.c
> @@ -0,0 +1,379 @@
> +/*
> + * dw-hdmi-codec.c
Doesn't match the filename. Is this line needed?
> + * DesignerWare ALSA SoC DAI driver for DW HDMI audio.
> + * Copyright (c) 2014, CORPORATION. All rights reserved.
> + * Authors: Yakir Yang
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.*
> + *
> + */
This states that the license is plain GPL v2.
(Missing empty line here.)
> +#include
[...]
> +MODULE_LICENSE("GPL");
So you probably want
MODULE_LICENSE("GPL v2");
here.
Paul Bolle
[PATCH 5/5] drm: bridge/dw_hdmi: add jz4780 support
Zubair Lutfullah Kakakhel schreef op wo 04-03-2015 om 15:37 [+]:
> --- /dev/null
> +++ b/drivers/gpu/drm/jz4780/dw_hdmi-jz4780.c
> @@ -0,0 +1,234 @@
> +/* Copyright (C) 2011-2013 Freescale Semiconductor, Inc.
> + * Copyright (C) 2015 Imagination Technologies Ltd.
> + *
> + * derived from dw_hdmi-imx.c
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
This states the license is GPL v2.
> +MODULE_LICENSE("GPL");
So you probably want
MODULE_LICENSE("GPL v2");
here.
Paul Bolle
[PATCH 3/5] drm: jz4780: Add DRM driver for Ingenic JZ4780
Zubair Lutfullah Kakakhel schreef op wo 04-03-2015 om 15:37 [+]:
> --- /dev/null
> +++ b/drivers/gpu/drm/jz4780/Makefile
> @@ -0,0 +1,10 @@
> +ccflags-y := -Iinclude/drm
> +ifeq (, $(findstring -W,$(EXTRA_CFLAGS)))
> +
> +endif
What does that do?
> +jz4780-y := \
> + jz4780_crtc.o \
> + jz4780_drv.o
Please make this one line.
> +obj-$(CONFIG_DRM_JZ4780) += jz4780.o
> --- /dev/null
> +++ b/drivers/gpu/drm/jz4780/jz4780_drv.c
> @@ -0,0 +1,388 @@
> +/*
> + * Copyright (C) 2015 Imagination Technologies
> + * Author: Zubair Lutfullah Kakakhel
> + *
> + * DRM driver for Ingenic JZ4780
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> by
> + * the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + *
> + */
This states the license is GPL v2. (I think the other files of this
driver carry similar comments.)
> +MODULE_LICENSE("GPL");
So you probably want
MODULE_LICENSE("GPL v2");
here.
Paul Bolle
[PATCH 2/2] drm/bridge: Add IT6151 bridge driver
Just a few nits, I'm afraid. On Wed, 2015-03-11 at 14:18 +0800, CK Hu wrote: > drivers/gpu/drm/bridge/Kconfig | 10 + > drivers/gpu/drm/bridge/Makefile | 1 + I applied 1/2 and 2/2 on top of next-20150312 to check a trivial issue. The chunks for these two files needed context changes to git this patch applied. > drivers/gpu/drm/bridge/it6151.c | 601 > > include/drm/bridge/it6151.h | 34 +++ > 4 files changed, 646 insertions(+) > create mode 100644 drivers/gpu/drm/bridge/it6151.c > create mode 100644 include/drm/bridge/it6151.h > diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig > index f38bbcd..2b3a78e 100644 > --- a/drivers/gpu/drm/bridge/Kconfig > +++ b/drivers/gpu/drm/bridge/Kconfig > @@ -11,3 +11,13 @@ config DRM_PTN3460 > select DRM_PANEL > ---help--- > ptn3460 eDP-LVDS bridge chip driver. > + > +config DRM_IT6151 > + bool "Enable IT6151FN : MIPI to eDP Converter" > + depends on DRM > + select DRM_KMS_HELPER > + help > + Choose this option if you have IT6151 for display > + The IT6151 is a high-performance and low-power > + MIPI to eDP converter > + (This empty line makes git am whine: "new blank line at EOF.".) > --- /dev/null > +++ b/drivers/gpu/drm/bridge/it6151.c > +#include This file can only be built-in. So I couldn't help but notice this include. And if I remove it make drivers/gpu/drm/bridge/it6151.o still runs without warning or errors. Unless I've missed something non-obvious I'd say it is not needed. > + (Empty line at end of file.) > --- /dev/null > +++ b/include/drm/bridge/it6151.h > + (Another empty line at end of file.) Paul Bolle
[git pull] drm fixes
Dave Airlie schreef op vr 06-03-2015 om 21:52 [+]: > Thierry Reding (1): > drm/mm: Support 4 GiB and larger ranges Yesterday the screen on my (outdated) ThinkPad X41 went, well, black while it was busy compiling something unattended. I eventually had to power cycle that laptop to regain control. I found a drm related BUG() in the logs (pasted at the end of the message). I only have three months worth of logs (a diagnoising session pushed most of the logs into /dev/null a few weeks ago). But this is the only time I saw that BUG in that period. Now that commit is the last thing touching that code, and the various unsigned long to u64 conversions _might_ just have gone wrong for 32 bits. I didn't spot anything utterly obvious in that commit, but point a finger at it just in case. Thanks, Paul Bolle mrt 12 19:29:00 x41 kernel: [ cut here ] mrt 12 19:29:00 x41 kernel: kernel BUG at drivers/gpu/drm/drm_mm.c:305! mrt 12 19:29:01 x41 kernel: invalid opcode: [#1] SMP mrt 12 19:29:01 x41 kernel: Modules linked in: bnep bluetooth fuse arc4 lib80211_crypt_wep ip6t_rpfilter ip6t_RE JECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_ tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_secur ity iptable_raw gpio_ich iTCO_wdt iTCO_vendor_support snd_intel8x0 snd_ac97_codec ppdev ipw2200 ac97_bus snd_seq sdhci_pci pcspkr serio_raw sdhci snd_seq_device libipw i2c_i801 mmc_core snd_pcm lpc_ich lib80211 thinkpad_acpi cfg80211 snd_timer irda snd parport_pc soundcore rfkill parport crc_ccitt acpi_cpufreq binfmt_misc i915 i2c_alg o_bit drm_kms_helper tg3 drm ptp ata_generic mrt 12 19:29:01 x41 kernel: yenta_socket pps_core pata_acpi video mrt 12 19:29:01 x41 kernel: CPU: 0 PID: 1749 Comm: gnome-shell Not tainted 4.0.0-0.rc3.1.local0.fc21.i686 #1 mrt 12 19:29:01 x41 kernel: Hardware name: IBM 2525FAG/2525FAG, BIOS 74ET64WW (2.09 ) 12/14/2006 mrt 12 19:29:02 x41 kernel: task: e17cc5e0 ti: e1696000 task.ti: e1696000 mrt 12 19:29:06 x41 kernel: EIP: 0060:[] EFLAGS: 00210206 CPU: 0 mrt 12 19:29:06 x41 kernel: EIP is at drm_mm_insert_node_in_range_generic+0x3b5/0x480 [drm] mrt 12 19:29:06 x41 kernel: EAX: 00df EBX: ef734c08 ECX: ef438d00 EDX: mrt 12 19:29:06 x41 kernel: ESI: ef734c00 EDI: ef734c00 EBP: e1697c6c ESP: e1697bf0 mrt 12 19:29:06 x41 kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 mrt 12 19:29:06 x41 kernel: CR0: 80050033 CR2: a24b7000 CR3: 21632000 CR4: 07d0 mrt 12 19:29:06 x41 kernel: Stack: mrt 12 19:29:07 x41 kernel: e1697c54 005f 0080 ef734c00 f6b0de00 mrt 12 19:29:07 x41 kernel: 0093 1000 0032 mrt 12 19:29:07 x41 kernel: 00c5 f6bb434c 0080 mrt 12 19:29:07 x41 kernel: Call Trace: mrt 12 19:29:09 x41 kernel: [] i915_gem_object_pin_view+0x666/0x8a0 [i915] mrt 12 19:29:09 x41 kernel: [] i915_gem_execbuffer_reserve_vma.isra.11+0x62/0x100 [i915] mrt 12 19:29:09 x41 kernel: [] i915_gem_execbuffer_reserve+0x2d9/0x350 [i915] mrt 12 19:29:09 x41 kernel: [] i915_gem_do_execbuffer.isra.16+0x65d/0xe00 [i915] mrt 12 19:29:09 x41 kernel: [] ? __kmalloc+0x1f5/0x250 mrt 12 19:29:09 x41 kernel: [] ? i915_gem_execbuffer2+0x59/0x2d0 [i915] mrt 12 19:29:09 x41 kernel: [] i915_gem_execbuffer2+0x8b/0x2d0 [i915] mrt 12 19:29:09 x41 kernel: [] ? i915_gem_execbuffer+0x510/0x510 [i915] mrt 12 19:29:09 x41 kernel: [] ? ktime_get+0x4a/0x110 mrt 12 19:29:09 x41 kernel: [] ? drm_getmap+0xc0/0xc0 [drm] mrt 12 19:29:09 x41 kernel: [] do_vfs_ioctl+0x322/0x540 mrt 12 19:29:09 x41 kernel: [] ? inode_has_perm.isra.32+0x32/0x50 mrt 12 19:29:09 x41 kernel: [] ? file_has_perm+0x97/0xa0 mrt 12 19:29:09 x41 kernel: [] ? selinux_file_ioctl+0x4b/0xe0 mrt 12 19:29:09 x41 kernel: [] SyS_ioctl+0x60/0x90 mrt 12 19:29:09 x41 kernel: [] sysenter_do_call+0x12/0x12 mrt 12 19:29:09 x41 kernel: Code: 05 0f 0b 8d 76 00 3b 55 e4 77 0b 72 05 3b 45 e0 73 04 0f 0b 66 90 8b 7d 98 03 47 20 13 57 24 3b 55 ec 72 12 77 05 3b 45 e8 76 0b <0f> 0b 89 f6 8d bc 27 00 00 00 00 39 55 cc 77 0b 72 05 39 45 b8 mrt 12 19:29:09 x41 kernel: EIP: [] drm_mm_insert_node_in_range_generic+0x3b5/0x480 [drm] SS:ESP 0068:e1697bf0 mrt 12 19:29:10 x41 kernel: ---[ end trace 3402b5fea7a4b768 ]---
[git pull] drm fixes
On Fri, 2015-03-13 at 12:36 +0100, Paul Bolle wrote:
> Dave Airlie schreef op vr 06-03-2015 om 21:52 [+]:
> > Thierry Reding (1):
> > drm/mm: Support 4 GiB and larger ranges
>
> Yesterday the screen on my (outdated) ThinkPad X41 went, well, black
> while it was busy compiling something unattended. I eventually had to
> power cycle that laptop to regain control. I found a drm related BUG()
> in the logs (pasted at the end of the message).
>
> I only have three months worth of logs (a diagnoising session pushed
> most of the logs into /dev/null a few weeks ago). But this is the only
> time I saw that BUG in that period. Now that commit is the last thing
> touching that code, and the various unsigned long to u64 conversions
> _might_ just have gone wrong for 32 bits. I didn't spot anything utterly
> obvious in that commit, but point a finger at it just in case.
Surely fixed by commit 046d669c62f3 ("[PATCH] drm/mm: Fix support 4 GiB
and larger ranges"). It corrects a mistake introduced by the commit
quoted above. So at least I pointed a finger at the right commit.
Thanks,
Paul Bolle
[git pull] drm fixes
On Mon, 2015-03-16 at 10:51 +0100, Thierry Reding wrote: > There should be a patch in v4.0-rc4 (046d669c62f3 "drm/mm: Fix support 4 > GiB and larger ranges") that presumably fixes this. Does it work for you > as well? I just sent a message that mentions that commit. It surely fixes this bug. v4.0-rc4 is still building on that ThinkPad X41. (This might take a while. But it is a proud little machine. It won't even consider running kernels build on present-day machines.) Unless you hear from me again, you may assume that commit works for me too. Paul Bolle
[PATCH v2] drm/i915: gen4: work around hang during hibernation
Imre Deak schreef op ma 02-03-2015 om 13:04 [+0200]:
> Bjørn reported that his machine hang during hibernation and eventually
> bisected the problem to the following commit:
>
> commit da2bc1b9db3351addd293e5b82757efe1f77ed1d
> Author: Imre Deak
> Date: Thu Oct 23 19:23:26 2014 +0300
>
> drm/i915: add poweroff_late handler
>
> The problem seems to be that after the kernel puts the device into D3
> the BIOS still tries to access it, or otherwise assumes that it's in D0.
> This is clearly bogus, since ACPI mandates that devices are put into D3
> by the OSPM if they are not wake-up sources. In the future we want to
> unify more of the driver's runtime and system suspend paths, for example
> by skipping all the system suspend/hibernation hooks if the device is
> runtime suspended already. Accordingly for all other platforms the goal
> is still to properly power down the device during hibernation.
>
> v2:
> - Another GEN4 Lenovo laptop had the same issue, while platforms from
> other vendors (including mobile and desktop, GEN4 and non-GEN4) seem
> to work fine. Based on this apply the workaround on all GEN4 Lenovo
> platforms.
> - add code comment about failing platforms (Ville)
The outdated ThinkPad X41 that I torture by running rc's showed
identical symptoms, also since v3.19-rc1. It uses a gen3 chipset (it has
a 915GM, I think, but I keep forgetting details like that).
I did everything wrong to get this fixed (1: hope this gets magically
fixed; 2: bisect it myself, thinking every now and then that I know
better than git bisect which commit to choose; 3: finally grep lkml). So
here I am late to the show.
> Reference:
> http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html
> Reported-and-bisected-by: Bjørn Mork
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_drv.c | 30 +-
> 1 file changed, 25 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 4badb23..ff3662f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -637,7 +637,7 @@ static int i915_drm_suspend(struct drm_device *dev)
> return 0;
> }
>
> -static int i915_drm_suspend_late(struct drm_device *drm_dev)
> +static int i915_drm_suspend_late(struct drm_device *drm_dev, bool
> hibernation)
> {
> struct drm_i915_private *dev_priv = drm_dev->dev_private;
> int ret;
> @@ -651,7 +651,17 @@ static int i915_drm_suspend_late(struct drm_device
> *drm_dev)
> }
>
> pci_disable_device(drm_dev->pdev);
> - pci_set_power_state(drm_dev->pdev, PCI_D3hot);
> + /*
> + * During hibernation on some GEN4 platforms the BIOS may try to access
> + * the device even though it's already in D3 and hang the machine. So
> + * leave the device in D0 on those platforms and hope the BIOS will
> + * power down the device properly. Platforms where this was seen:
> + * Lenovo Thinkpad X301, X61s
> + */
> + if (!(hibernation &&
> + drm_dev->pdev->subsystem_vendor == PCI_VENDOR_ID_LENOVO &&
> + INTEL_INFO(dev_priv)->gen == 4))
> + pci_set_power_state(drm_dev->pdev, PCI_D3hot);
>
> return 0;
> }
I'll paste a DRAFT patch that fixes this for that X41 at the end of the
message. The patch is rather ugly. Should we perhaps try a quirk table
or something like that?
Paul Bolle
>8
Subject: [PATCH] drm/i915: work around hang during hibernation on gen3 too
Commit ab3be73fa7b4 ("drm/i915: gen4: work around hang during
hibernation") was targetted at gen4 platforms shipped by Lenovo. The
same problem can also be seen on a Lenovo ThinkPad X41. Expand the test
to catch that system too.
Sadly, this system still uses IBM's subsystem vendor id. So we end up
with a rather unpleasant test. Use the IS_GEN3() and IS_GEN4() macros to
lessen the pain a bit.
Not-yet-signed-off-by: Paul Bolle
---
drivers/gpu/drm/i915/i915_drv.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index cc6ea53d2b81..3a07164f5860 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -641,11 +641,12 @@ static int i915_drm_suspend_late(struct drm_device
*drm_dev, bool hibernation)
* the device even though it's already in D3 and hang the machine. So
* leave the device in D0 on those platforms and hope the BIOS will
* power down the device properly. Platforms where this was seen:
-* Lenovo Thinkpad X301, X61s
+* Lenovo Thinkpad X301, X61s, X41
*/
if (!(hibernation &&
-
[PATCH v2] drm/i915: gen4: work around hang during hibernation
On Wed, 2015-03-18 at 12:22 +0200, Ville Syrjälä wrote: > We had another bug report which showed similar problems on something > as recent as SNB: > https://bugzilla.kernel.org/show_bug.cgi?id=94241 > So I guess we really want to make the check 'gen < 7'. > > My IVB X1 Carbon doesn't need this quirk, so hopefully that indicates > the Lenovo BIOSen became more sane for gen7+. On the other hand my ThinkPad X220 has vendor:device ids 8086:0126, which makes it a gen6 device (assuming I parsed the various preprocessor defines in include/drm/i915_pciids.h and drivers/gpu/drm/i915/i915_drv.c correctly). That laptop is now running v3.19.1 and never hit this issue. Paul Bolle
[PATCH] Add virtio gpu driver.
Just a license nit.
On Tue, 2015-03-24 at 17:07 +0100, Gerd Hoffmann wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/virtio/virtgpu_drv.c
> @@ -0,0 +1,132 @@
> +/*
> + * 2011 Red Hat, Inc.
> + * All Rights Reserved.
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
I wouldn't know (without further, well, research) which license this is.
> +MODULE_LICENSE("GPL");
But I'm pretty sure it's not GPL v2 or later. So I think the license
mentioned in the comment at the top of this file and the license "ident"
used in this macro do not match.
Paul Bolle
[PATCH] drm/vmwgfx: use *_32_bits() macros
On do, 2016-03-03 at 11:26 +0100, Paul Bolle wrote: > Use the upper_32_bits() macro instead of the four line equivalent that > triggers a GCC warning on 32 bits x86: > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c: In function > 'vmw_cmdbuf_header_submit': > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c:297:25: warning: right > shift count >= width of type [-Wshift-count-overflow] >val = (header->handle >> 32); > ^ > > And use the lower_32_bits() macro instead of and-ing with a 32 bits > mask. > > Signed-off-by: Paul Bolle > --- > Note: compile tested only (I don't use any of vmware's products). The warning can still be seen on v4.6-rc3 for 32 bits x86. This patch applies cleanly to that rc. Has anyone had a chance to look at this patch, and perhaps even test it? Thanks, Paul Bolle > drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c > b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c > index 67cebb23c940..aa04fb0159a7 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c > @@ -293,13 +293,10 @@ static int vmw_cmdbuf_header_submit(struct > vmw_cmdbuf_header *header) > struct vmw_cmdbuf_man *man = header->man; > u32 val; > > - if (sizeof(header->handle) > 4) > - val = (header->handle >> 32); > - else > - val = 0; > + val = upper_32_bits(header->handle); > vmw_write(man->dev_priv, SVGA_REG_COMMAND_HIGH, val); > > - val = (header->handle & 0xULL); > + val = lower_32_bits(header->handle); > val |= header->cb_context & SVGA_CB_CONTEXT_MASK; > vmw_write(man->dev_priv, SVGA_REG_COMMAND_LOW, val); >
[PATCH v2 1/2] create SMAF module
A nit only, I'm afraid: a license mismatch.
On ma, 2015-07-06 at 13:40 +0200, Benjamin Gaignard wrote:
> --- /dev/null
> +++ b/drivers/smaf/smaf-core.c
> + * License terms: GNU General Public License (GPL), version 2
> +MODULE_LICENSE("GPL");
The comment at the top of this file states, succinctly, that the license
is GPL v2. And, according to include/linux/module.h, the
MODULE_LICENSE() macro here states that the license is GPL v2 or later.
So I think that either that comment or the ident used in that macro
needs to change.
Ditto for 2/2.
Thanks,
Paul Bolle
[PATCH v7 1/4] drm/layerscape: Add Freescale DCU DRM driver
A question and a nit follow.
On vr, 2015-07-10 at 19:17 +0800, Jianwei Wang wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
> +MODULE_ALIAS("platform:fsl-dcu-drm");
Question: this appears to be only useful if there's a corresponding
struct platform_device. That is, a platform_device with a "fsl-dcu-drm"
.name. It will fire off a "MODALIAS=platform:fsl-dcu-drm" uevent when
it's created.
I couldn't find this corresponding platform_device. Does it exist? Or is
this alias needed for some other reason?
> --- /dev/null
> +++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
> +#define DRIVER_NAME "fsl-dcu-drm"
Nit: I don't think DRIVER_NAME is actually used anywhere.
Thanks,
Paul Bolle
[PATCH] drm/i915: Remove references to previously removed UMS config option
On Fri, 2015-02-06 at 11:16 +0100, Andreas Ruprecht wrote:
> Commit 03dae59c72d8 ("drm/i915: Ditch UMS config option") removed
> CONFIG_DRM_I915_UMS from the Kconfig file, but i915_drv.c still
> references this option in two #ifndef statements.
>
> As an undefined config option will always be 'false', we can drop
> the #ifndefs alltogether and adapt the printed error message.
>
> This inconsistency was found with the undertaker tool.
>
> Signed-off-by: Andreas Ruprecht
> ---
Previously discussed in
http://lists.freedesktop.org/archives/dri-devel/2014-July/064702.html
(but not on lkml). If I understand Daniels message correctly this
$ git grep -n '!drm_core_check_feature' | grep -w DRIVER_MODESET | wc -l
43
means the cleanup needed to be done before this cleanup will be applied,
hasn't happened yet.
> drivers/gpu/drm/i915/i915_drv.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 8039cec..4ecf85f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1630,11 +1630,9 @@ static int __init i915_init(void)
>
> if (!(driver.driver_features & DRIVER_MODESET)) {
> driver.get_vblank_timestamp = NULL;
> -#ifndef CONFIG_DRM_I915_UMS
> /* Silently fail loading to not upset userspace. */
> - DRM_DEBUG_DRIVER("KMS and UMS disabled.\n");
> + DRM_DEBUG_DRIVER("KMS disabled.\n");
> return 0;
> -#endif
> }
>
> /*
> @@ -1650,10 +1648,8 @@ static int __init i915_init(void)
>
> static void __exit i915_exit(void)
> {
> -#ifndef CONFIG_DRM_I915_UMS
> if (!(driver.driver_features & DRIVER_MODESET))
> return; /* Never loaded a driver. */
> -#endif
>
> drm_pci_exit(, _pci_driver);
> }
Thanks,
Paul Bolle
[BISECTED REGRESSION in 3.19-rc1] [drm/i915] WARNING: drivers/gpu/drm/drm_irq.c:1077 drm_wait_one_vblank
Andrey Skvortsov schreef op wo 04-02-2015 om 20:26 [+0300]: > On Wed, Feb 04, 2015 at 01:32:14PM +0100, Paul Bolle wrote: > > Andrey Skvortsov schreef op zo 01-02-2015 om 00:16 [+0300]: > > > this warning exist in v3.19-rc6 and does not in v3.18. Bisection > > > points to the commit 51e31d49c890552 "drm/i915: Use generic vblank wait". > > > I have two machines with integrated Intel graphics and the problem > > > happens only on the old one with GM965 chipset and X3100 integrated > > > graphics. > > > > I see this too, since v3.19-rc1, on an (outdated) ThinkPad X41. > > > > > backtrace information: > > > > > > [ 31.780813] WARNING: CPU: 0 PID: 718 at drivers/gpu/drm/drm_irq.c:1077 > > > drm_wait_one_vblank+0x33/0x141 [drm]() > > > > But it also prints > > vblank not available on crtc 0, ret=-22 > > > > after the WARNING line, on that machine. > > I have "vblank not available on crtc 1, ret=-22" there. > > > > > [ 31.780862] thermal_sys(E) > > > [ 31.780866] CPU: 0 PID: 718 Comm: kworker/u4:3 Tainted: GE > > > 3.17.0-rc5-150116--00578-g51e31d4 #16 > > > [ 31.780868] Hardware name: Dell Inc. Vostro 1500 > > > /0NX907, BIOS A06 04/21/2008 > > > [ 31.780873] Workqueue: events_unbound async_run_entry_fn > > > [ 31.780875] a0544b9d 813d4e81 > > > > > > [ 31.780879] 8103dec3 8800d84e0068 a0521c73 > > > 00070008 > > > [ 31.780882] 8800d84e 8801973e0800 > > > 6014 > > > [ 31.780886] Call Trace: > > > [ 31.780890] [] ? dump_stack+0x4a/0x75 > > > [ 31.780894] [] ? warn_slowpath_common+0x7e/0x97 > > > [ 31.781050] [] ? drm_wait_one_vblank+0x33/0x141 > > > [drm] > > > [ 31.781078] [] ? drm_wait_one_vblank+0x33/0x141 > > > [drm] > > > [ 31.781122] [] ? intel_enable_tv+0x22/0x58 [i915] > > > [ 31.781153] [] ? i9xx_crtc_enable+0x33b/0x397 [i915] > > > [ 31.781184] [] ? __intel_set_mode+0x1160/0x1209 > > > [i915] > > > [ 31.781216] [] ? intel_set_mode+0x12/0x2c [i915] > > > [ 31.781247] [] ? > > > intel_get_load_detect_pipe+0x367/0x408 [i915] > > > [ 31.781281] [] ? intel_tv_detect+0x103/0x444 [i915] > > > [ 31.781289] [] ? > > > drm_helper_probe_single_connector_modes_merge_bits+0xc0/0x327 > > > [drm_kms_helper] > > > [ 31.781296] [] ? > > > drm_fb_helper_probe_connector_modes+0x3d/0x51 [drm_kms_helper] > > > [ 31.781303] [] ? > > > drm_fb_helper_initial_config+0x3d/0x303 [drm_kms_helper] > > > [ 31.781306] [] ? async_run_entry_fn+0x5a/0x110 > > > [ 31.781310] [] ? process_one_work+0x194/0x292 > > > [ 31.781313] [] ? worker_thread+0x236/0x298 > > > [ 31.781316] [] ? process_scheduled_works+0x2a/0x2a > > > [ 31.781319] [] ? kthread+0x9e/0xa6 > > > [ 31.781322] [] ? > > > kthread_freezable_should_stop+0x36/0x36 > > > [ 31.781326] [] ? ret_from_fork+0x7c/0xb0 > > > [ 31.781329] [] ? > > > kthread_freezable_should_stop+0x36/0x36 > > > [ 31.782726] ---[ end trace e2b78017f1a10054 ]--- I still see this on v3.19. I booted with drm.debug=0x4. The almost 2K lines in dmesg containing either "[drm" or this WARNING are pasted below. I really know nothing about all this, but I do note that only the WARNINGS are preceded by: [drm:intel_calculate_wm] FIFO watermark level: -5 [drm:i9xx_update_wm] FIFO watermarks - A: 26, B: 8 But perhaps that's another symptom of the same issue. A bit of staring at the code couldn't help me determine that. Perhaps these debug messages help someone in discovering what might be going on here. Paul Bolle <6>[2.537208] [drm] Initialized drm 1.1.0 20060810 <7>[2.845633] [drm:intel_detect_pch] No PCH found. <6>[2.845642] [drm] Memory usable by graphics device = 256M <6>[2.846625] [drm] Replacing VGA console driver <6>[2.848689] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). <6>[2.848695] [drm] Driver supports precise vblank timestamp query. <7>[2.848700] [drm:init_vbt_defaults] Set default to SSC at 10 kHz <7>[2.848735] [drm:validate_vbt] Using VBT from PCI ROM: $VBT ALVISO d <7>[2.848739] [drm:parse_general_features] BDB_GENERAL_FEATURES int_tv_support 1 int_crt_support 0 lvds_use_ssc 1 lvds_ssc_freq 10 display_clock_mode 0 fdi_rx_polari
drm/exynos: DRM_EXYNOS7DECON?
Your commit 96976c3d9aff ("drm/exynos: Add DECON driver") is included in
today's linux-next (ie, next-20150217). I noticed because a script I use
to check linux-next spotted a problem with it.
It added an (optional) dependency on DRM_EXYNOS7DECON instead of
DRM_EXYNOS7_DECON (see drivers/gpu/drm/exynos/Kconfig). Is the trivial
patch to correct this typo queued somewhere? (This assumes an optional
dependency on DRM_EXYNOS7_DECON is actually needed for DRM_EXYNOS_DP, of
course.)
Paul Bolle
[PATCH] drm/radeon/rv515: Remove unused function
ZC_FLUSH | ZC_FREE);
> >> - radeon_ring_write(ring, PACKET0(GB_MSPOS0, 0));
> >> - radeon_ring_write(ring,
> >> - ((6 << MS_X0_SHIFT) |
> >> - (6 << MS_Y0_SHIFT) |
> >> - (6 << MS_X1_SHIFT) |
> >> - (6 << MS_Y1_SHIFT) |
> >> - (6 << MS_X2_SHIFT) |
> >> - (6 << MS_Y2_SHIFT) |
> >> - (6 << MSBD0_Y_SHIFT) |
> >> - (6 << MSBD0_X_SHIFT)));
> >> - radeon_ring_write(ring, PACKET0(GB_MSPOS1, 0));
> >> - radeon_ring_write(ring,
> >> - ((6 << MS_X3_SHIFT) |
> >> - (6 << MS_Y3_SHIFT) |
> >> - (6 << MS_X4_SHIFT) |
> >> - (6 << MS_Y4_SHIFT) |
> >> - (6 << MS_X5_SHIFT) |
> >> - (6 << MS_Y5_SHIFT) |
> >> - (6 << MSBD1_SHIFT)));
> >> - radeon_ring_write(ring, PACKET0(GA_ENHANCE, 0));
> >> - radeon_ring_write(ring, GA_DEADLOCK_CNTL | GA_FASTSYNC_CNTL);
> >> - radeon_ring_write(ring, PACKET0(GA_POLY_MODE, 0));
> >> - radeon_ring_write(ring, FRONT_PTYPE_TRIANGE | BACK_PTYPE_TRIANGE);
> >> - radeon_ring_write(ring, PACKET0(GA_ROUND_MODE, 0));
> >> - radeon_ring_write(ring, GEOMETRY_ROUND_NEAREST |
> >> COLOR_ROUND_NEAREST);
> >> - radeon_ring_write(ring, PACKET0(0x20C8, 0));
> >> - radeon_ring_write(ring, 0);
> >> - radeon_ring_unlock_commit(rdev, ring, false);
> >> -}
> >> -
> >> int rv515_mc_wait_for_idle(struct radeon_device *rdev)
> >> {
> >> unsigned i;
> >> --
> >> 1.7.10.4
Paul Bolle
[PATCH 6/8] pwm: crc: Add Crystalcove (CRC) PWM driver
On Tue, 2015-05-05 at 15:08 +0530, Shobhit Kumar wrote: > The Crystalcove PMIC controls PWM signals and this driver exports that > capability as a PWM chip driver. This is platform device implementtaion > of the drivers/mfd cell device for CRC PMIC > > v2: Use the existing config callback with duty_ns and period_ns(Thierry) > > v3: Correct the subject line (Lee jones) > > CC: Samuel Ortiz > Cc: Linus Walleij > Cc: Alexandre Courbot > Cc: Thierry Reding > Signed-off-by: Shobhit Kumar The same comments can be made as for v2, see http://lkml.kernel.org/r/1430428322.2187.24.camel at x220 . Maybe you didn't receive that message. It could also be that you think my comments were invalid, or too vague, or whatever. Please say so, because then I don't have to bother you again when you send out v4. Thanks, Paul Bolle
[RFC][PATCH 2/2] drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.
A naive question and a nit follow. That's probably not what you'd like
to see for an RFC, but the patch got tangled up in my mail filter
anyhow.
On Wed, 2015-05-13 at 23:23 +0800, CK Hu wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/Kconfig
> +config DRM_MEDIATEK_FBDEV
> + bool "Enable legacy fbdev support for Mediatek DRM"
> + depends on DRM_MEDIATEK
> + select FB_SYS_FILLRECT
> + select FB_SYS_COPYAREA
> + select FB_SYS_IMAGEBLIT
> + select DRM_KMS_FB_HELPER
> + help
> + Choose this option if you have a need for the legacy
> + fbdev support. Note that this support also provides
> + the Linux console on top of the Mediatek DRM mode
> + setting driver.
Naive question, as I know next to nothing about drivers/gpu/drm.
DRM_MEDIATEK_FBDEV isn't used anywhere, as far as I can see. So all that
setting this Kconfig symbol does is selecting four other Kconfig
symbols. Is selecting those four symbols enough to get fbdev support?
Taking the Cargo Cult approach of looking at similar symbols
(DRM_I915_FBDEV, DRM_MSM_FBDEV, DRM_STI_FBDEV, and DRM_TEGRA_FBDEV) I
noticed that they all do a bit more than just selecting other symbols.
> --- /dev/null
> +++ b/drivers/gpu/drm/mediatek/mediatek_drm_drv.c
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
This states the license of this driver is GPL v2. (Identical comments
seem to be part of all files added in this patch.)
> +MODULE_LICENSE("GPL");
And, according to include/linux/module.h, this states the license is GPL
v2 or later. So I think that either the comment at the top of these
files or the ident used in the MODULE_LICENSE() macro needs to be
changed.
Thanks,
Paul Bolle
[RESEND PATCH v1 2/2] drm: bridge/dw_hdmi-i2s-audio: add audio driver
Just a nit: a license mismatch.
On Fri, 2015-05-22 at 10:14 -0500, Yakir Yang wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/bridge/dw_hdmi-i2s-audio.c
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
This states the license is GPL v2.
> +MODULE_LICENSE("GPL");
And, according to include/linux/module.h, this states the license is GPL
v2 or later. So I think that either the comment at the top of this file
or the ident used in the MODULE_LICENSE() macro should change.
Paul Bolle
[PATCH] [RFC] drm/radeon: return 0 on successful gpu reset
On an (outdated) laptop the radeon driver (almost always) prints, during
the first resume of each session:
[drm] crtc 1 is connected to a TV
This message is a bit puzzling as, as far as I know, no TV has ever
been connected to this laptop. Anyhow, before v3.5, if that happened the
radeon driver then printed an error during all following resumes:
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -35!
(-35 is -EDEADLK.) But the resume would succeed and the driver seemed to
run without too much trouble. From v3.5 onwards things changed. If the
(puzzling) message about crtc 1 was printed on first resume the laptop
would simply hang on second resume. Only a manual power off would then
be possible. In that case nothing of interest would be found in the
(truncated) logs. And, most annoyingly, the hang would never happen if
the laptop was booted with, say, "console=ttyS0,115200n8" added to the
kernel command line.
I bisected the hang to commit 6c6f478370eccfbfafbdc6fc55c0def03e58f124
("drm/radeon: rework recursive gpu reset handling"), which was added in
the v3.5 release cycle. After discovering that and poking at the driver
it turned out that this hang is triggered by radeon_cs_handle_lockup()
returning -EAGAIN after successfully resetting the gpu. Simply returning
0 makes the hang disappear (and makes the drm error reappear).
Nothing in the code or the commit explanation clarifies why -EAGAIN
should be returned on successful gpu reset. So I suggest
radeon_cs_handle_lockup() simply returns what radeon_gpu_reset()
returns, eg 0 (on success) or a negative error code (on failure).
Signed-off-by: Paul Bolle
---
0) This exact patch is untested (but I run something comparable).
1) Sent as an RFC because I do not understand why this laptop (almost
always) prints the "crtc 1" message on first resume. Note that another
workaround for this hang is simply booting with "radeon.tv=0".
2) Also sent as an RFC because I have no idea whatsoever why returning
-EAGAIN will hang the machine. I guess it's returned to userland by
radeon_cs_ioctl(). What code uses that ioctl? And what does that code do
on -EAGAIN that hangs this laptop?
3) A third reason to send this as an RFC is that I also have no idea why
this hang doesn't happen when booting with "console=ttyS0,115200n8" or
even "console=tty0"! But I guess I'm now allowed to call this hang a
Heisenbug.
drivers/gpu/drm/radeon/radeon_cs.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 41672cc..a302c00 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -486,11 +486,8 @@ out:
static int radeon_cs_handle_lockup(struct radeon_device *rdev, int r)
{
- if (r == -EDEADLK) {
+ if (r == -EDEADLK)
r = radeon_gpu_reset(rdev);
- if (!r)
- r = -EAGAIN;
- }
return r;
}
--
1.7.7.6
[PATCH] [RFC] drm/radeon: return 0 on successful gpu reset
On Tue, 2012-12-18 at 10:22 -0500, Alex Deucher wrote: > On Tue, Dec 18, 2012 at 5:36 AM, Christian K?nig > wrote: > > On 17.12.2012 22:31, Paul Bolle wrote: > >> 1) Sent as an RFC because I do not understand why this laptop (almost > >> always) prints the "crtc 1" message on first resume. Note that another > >> workaround for this hang is simply booting with "radeon.tv=0". > > > > Alex should probably take a look into this, since he probably is the one > > with the deepest knowledge of the display engine. My best guess is that it > > is just some error while probing for an attached TV and actually isn't so > > bad after all. > > TV detection is always a bit flakey. I suspect some register or gpio > related to TV out doesn't get restored properly on resume which > results in a false positive. What asic is this? It's an RV250, which makes the asic r200, doesn't it? > > You should definitely try Alex latest drm-fixes-3.8 branch > > (git://people.freedesktop.org/~agd5f/linux) since the possibility is quite > > high that we already have fixed that bug. If that doesn't helps then please > > open a bug report and leave me a note so that I can investigate further. > > I don't have a 3.8 fixes branch up just yet, but will soon. I see. I'll watch that repository, but I would appreciate it if you notify me if that branch pops up. Paul Bolle
[PATCH] [RFC] drm/radeon: return 0 on successful gpu reset
On Thu, 2012-12-20 at 13:37 -0500, Alex Deucher wrote:
> On Tue, Dec 18, 2012 at 12:28 PM, Paul Bolle wrote:
> > On Tue, 2012-12-18 at 10:22 -0500, Alex Deucher wrote:
> >> On Tue, Dec 18, 2012 at 5:36 AM, Christian K?nig
> >> wrote:
> >> > You should definitely try Alex latest drm-fixes-3.8 branch
> >> > (git://people.freedesktop.org/~agd5f/linux) since the possibility is
> >> > quite
> >> > high that we already have fixed that bug. If that doesn't helps then
> >> > please
> >> > open a bug report and leave me a note so that I can investigate further.
> >>
> >> I don't have a 3.8 fixes branch up just yet, but will soon.
> >
> > I see. I'll watch that repository, but I would appreciate it if you
> > notify me if that branch pops up.
>
> http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-3.8
Thanks.
I tried drm-fixes-3.8, at commit
4613ca14b9739428abb53bef9cd0f8b3fee23a95 ("drm/radeon: add support for
MEM_WRITE packet"), on top of v3.7. It hangs in the exact same way.
Christian, were should I open a bug, and under which component, etc.?
Paul Bolle
i915: kernel errors at resume
0) On a laptop I use I've ran into i915 kernel errors at resume. I see these only every now and then: not on all resumes. The pattern of these errors (and preceding messages) is basically always like this: <6>[14673.762529] [drm] Changing LVDS panel from (+hsync, +vsync) to (-hsync, -vsync) <6>[14673.824599] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state <3>[14673.825071] render error detected, EIR: 0x0010 <3>[14673.825071] page table error <3>[14673.825071] PGTBL_ER: 0x0100 <3>[14673.825071] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: 0x0010, masking 1) I've only noticed this because: - I tend to check for KERN_ERR messages in the logs; and - the errors (ie, the messages with a <3> prefix) look scary when text mode briefly flashes by at suspend and at resume. Otherwise the display on this machine seems to work just fine. 2) The logs on this machine only have information for v3.3 based kernels. I haven't checked whether earlier kernels also do this. Nor have I checked whether this is fixed in the current v3.4 release candidates. 3) Some similar reports, but for messages printed at boot: http://lists.freedesktop.org/archives/dri-devel/2011-January/007302.html http://lists.freedesktop.org/archives/dri-devel/2012-January/018158.html 4) What can I do to (help) make these messages go away? Paul Bolle
