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
/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
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
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
://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
() 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
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
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
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
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
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
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
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
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
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
[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 betw
out 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_rp
cially since hitting this WARNING sometimes takes over an hour.
Anyhow, please prod me if I stay silent for too long.
Thanks,
Paul Bolle
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
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 po
e 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
rs:
   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 bre
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
[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() macr
hose 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
ds 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
ype [-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/vmw
> + /*
> + * 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
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
ot
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
y think it's as simple as that.
Paul Bolle
be submitted in actual working condition.
Paul Bolle
=]
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
n_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
e 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
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 comm
gt;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
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/
ill always evaluate to true.
Is the trivial cleanup to remove them already queued somewhere?
Paul Bolle
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
> &
could release a BIOS update to
fix this, what should I ask them to do?
Paul Bolle
[] ? __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
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 th
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
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
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
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
o it
seems these lines should be wrapped with a preprocessor check for
CONFIG_MSM_OCMEM too.
Paul Bolle
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_O
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
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 x8
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) {
> >
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
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
() 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
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
t;
> 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
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 tha
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
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 mak
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
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 ([.
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'
"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&quo
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
s 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/teg
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
aive 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
rked?
>
> 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
AGP thingy, and/or broken RV250 (or the interaction of
these things or whatever). Maddening stuff, impossible to debug.
Good luck,
Paul Bolle
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
> >
> >&
itting this, but with
PCI_SUBVENDOR_ID_IBM involved.
Paul Bolle
n 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
mi-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
end up in v3.19-stable in due time.
Paul Bolle
lic 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
t; + * 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
MODULE_LICENSE("GPL");
So you probably want
MODULE_LICENSE("GPL v2");
here.
Paul Bolle
his 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
ldn'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
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
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
ixes 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
v->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. Th
/gpu/drm/i915/i915_drv.c
correctly). That laptop is now running v3.19.1 and never hit this issue.
Paul Bolle
ow (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
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/
op 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
+ 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
_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
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
> >
rs/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
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
l.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
. 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
t used in the MODULE_LICENSE() macro should change.
Paul Bolle
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 l
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 "cr
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 d
ts, 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
1 - 100 of 105 matches
Mail list logo
