On Sun, Mar 06, 2016 at 10:02:30PM +, Robin H. Johnson wrote:
> Introduce PCI_VENDOR/PCI_SUBVENDOR/PCI_SUBDEVICE defines to replace the
> constants scattered in the kernel already used to detect QEMU.
>
> They are defined in the QEMU codebase per docs/specs/pci-ids.txt.
>
> Signed-off-by: Rob
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/bba91413/attachment.html>
type||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/b3493670/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=113861
Bug ID: 113861
Summary: [radeon] Xorg fatal freeze upon startx
Product: Drivers
Version: 2.5
Kernel Version: 4.4.4, 4.1.18 LTS
Hardware: All
OS: Linux
Tree: M
https://bugzilla.kernel.org/show_bug.cgi?id=113861
--- Comment #1 from 3db5to+dsqmzpq58ju3k at sharklasers.com ---
Note there are NO Xorg.0.log produced, full freeze.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=113861
--- Comment #2 from centuryplague at yandex.com ---
"It is not happening on 4.4.3 from distribution (but pure vanilla not tried)."
(but note 4.4.2 was tried which was vanilla + grsec, and had no problems... so
likely a change in 4.4.4 exactly trig
On Mon, Mar 07, 2016 at 12:09:51AM +0200, Michael S. Tsirkin wrote:
> On Sun, Mar 06, 2016 at 10:02:30PM +, Robin H. Johnson wrote:
> > Introduce PCI_VENDOR/PCI_SUBVENDOR/PCI_SUBDEVICE defines to replace the
> > constants scattered in the kernel already used to detect QEMU.
> >
> > They are de
Hi Tomi,
Thank you for the patch.
On Monday 22 February 2016 19:10:07 Tomi Valkeinen wrote:
> For legacy reasons omapdss handles system suspend/resume via PM notifier
> callback, where the driver disables/resumes all the outputs.
>
> This doesn't work well with omapdrm. What happens on suspend i
Hi Tomi,
Thank you for the patch.
On Monday 22 February 2016 19:10:08 Tomi Valkeinen wrote:
> core.c is the only caller of dss_disable_all_devices(). We can thus move
> the function from display.c to core.c and make it static.
>
> Signed-off-by: Tomi Valkeinen
Acked-by: Laurent Pinchart
> --
Hi Tomi,
Thank you for the patch.
On Monday 22 February 2016 19:10:09 Tomi Valkeinen wrote:
> 'struct omap_dss_hdmi_data' is not used anywhere, so we can remove it.
>
> Signed-off-by: Tomi Valkeinen
Acked-by: Laurent Pinchart
> ---
> include/video/omapdss.h | 7 ---
> 1 file changed, 7
Hi Tomi,
Thank you for the patch.
On Monday 22 February 2016 19:10:10 Tomi Valkeinen wrote:
> omap_hdmi_init() function does not exist anymore, so we can remove the
> declaration.
>
> Signed-off-by: Tomi Valkeinen
Acked-by: Laurent Pinchart
> ---
> include/video/omapdss.h | 2 --
> 1 file c
ctivate_after_resume) {
>> +dssdev->driver->enable(dssdev);
>> +dssdev->activate_after_resume = false;
>> +}
>> +}
>> +
>> +return 0;
>> +}
>> +
>> static int omap_drm_suspend(struct device *dev)
>> {
>> struct drm_device *drm_dev = dev_get_drvdata(dev);
>>
>> drm_kms_helper_poll_disable(drm_dev);
>>
>> +drm_modeset_lock_all(drm_dev);
>
> The omapdss implementation of the suspend and resume handlers didn't take the
> modeset locks. I wonder what we're trying to protect against here, what other
> concurrent task(s) could race us ?
The description explains at least one case I was encountering. To be
honest, the new code doesn't feel very good either, but at least the
entry point is now in omapdrm, and protected with a lock, so it should
be much safer.
As for what else is there... I hope not much. The panel/encoder drivers
can execute code in an interrupt or possibly even via a sysfs file if
someone would add things like that, and at the moment we don't have
means to properly deal with it. But afaik the current drivers don't do
any of those.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/0b82f2fc/attachment.sig>
Hi Tomi,
Thank you for the patch.
On Monday 22 February 2016 19:10:11 Tomi Valkeinen wrote:
> We no longer have any boards that require the platform data support from
> the panel, so we can remove the related code.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/omapdrm/displays/panel
r;
>> -} else if (pdev->dev.of_node) {
>> -r = dsicm_probe_of(pdev);
>> -if (r)
>> -return r;
>> -} else {
>> +if (pdev->dev.of_node)
>
> Shouldn't you invert the condition ?
Oops... Thanks for catching this.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/5cf2c4e0/attachment.sig>
Hi Tomi,
Thank you for the patch.
On Monday 22 February 2016 19:10:13 Tomi Valkeinen wrote:
> We no longer have any boards that require the platform data support from
> the connector, so we can remove the related code.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/omapdrm/displays/
ode)
>
> I think you need to invert the condition.
Thanks! Well, I obviously wasn't too careful here... I'll go through all
of them.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 b
On 2016å¹´03æ05æ¥ 20:39, Russell King - ARM Linux wrote:
> On Sat, Mar 05, 2016 at 12:11:16PM +, John Keeping wrote:
>> On Fri, Mar 04, 2016 at 03:22:01PM -0800, Douglas Anderson wrote:
>>> The drm_encoder_cleanup() was missing both from the error path of
>>> dw_hdmi_rockchip_bind(). This c
Hi Tomi,
Thank you for the patch.
On Monday 22 February 2016 19:10:20 Tomi Valkeinen wrote:
> omapdrm and omapfb still share the same include/video/omapdss.h. We need
> to change that so that we can proceed with omapdrm work.
>
> However, it's not trivial to make separate omapfb and omapdrm vers
server or equivalent.
Thanks,
pq
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/092dc2bc/attachment.sig>
Hi Tomi,
Thank you for the patch.
On Monday 22 February 2016 19:10:23 Tomi Valkeinen wrote:
> We are removing the use of the 'struct omap_overlay_manager' from
> omapdrm, and one part of that is removing the use of
> mgr->supported_outputs field.
>
> This patch adds dispc_mgr_get_supported_outpu
Hi Tomi,
Thank you for the patch.
On Monday 22 February 2016 19:10:24 Tomi Valkeinen wrote:
> In order to remove uses of 'struct omap_overlay_manager' from omapdrm,
> this patch removes the crtc->mgr field.
>
> To accomplish that, a new static array is added along the current
> 'omap_crtcs' stat
t from
omapdss.h, I can't remove them just like that.
Probably I should create a new header for omapfb. Or maybe a new one for
the parts used from arch/.
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/2e8ed2a0/attachment.sig>
Hi Tomi,
Thank you for the patch.
On Monday 22 February 2016 19:10:46 Tomi Valkeinen wrote:
> We have now removed all uses of 'struct omap_overlay_manager', so we can
> now remove the last places where it is set.
Shouldn't you also move the definition of the structure to a header private to
oma
?
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/72b8e1e0/attachment.sig>
ed...
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/c9564558/attachment.sig>
output[8];
>
> We should really move away from global structures, not adding more of them
> :-/
> Could you add this to your (or my) todo list ?
Agreed.
This restructuring series was becoming quite large and confusing
already, and I didn't see an obvious solution to this prob
https://bugzilla.kernel.org/show_bug.cgi?id=113341
--- Comment #6 from Michel Dänzer ---
Any chance you could try if this also happens with LLVM 3.8 or even current
SVN/Git?
Does it always happen when starting a particular application?
--
You are receiving this mail because:
You are watching
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/e1b8155a/attachment.html>
Hi,
> > Digged the mails up in the archive.
> >
> Silly me assumed that the MUA will bring up the the whole thread.
If your mbox goes back that far ...
I usually have a few months history in my mailbox folders which is
enough in the vast majority of the cases where I have to check some past
ma
Hi Tomi,
On Monday 07 March 2016 10:54:05 Tomi Valkeinen wrote:
> On 07/03/16 10:42, Laurent Pinchart wrote:
> > On Monday 22 February 2016 19:10:20 Tomi Valkeinen wrote:
> >> omapdrm and omapfb still share the same include/video/omapdss.h. We need
> >> to change that so that we can proceed with o
2016-03-05 0:32 GMT+08:00 Daniel Vetter :
> Adding relevant mailing lists and people. Please don't send private
> mails to maintainers ;-)
Thank you for the reply and pointing it.
> On Fri, Mar 4, 2016 at 1:47 PM, Chih-Wei Huang
> wrote:
>> Hi Daniel,
>> This is the Android-x86 project.
>> I'm
Hi, Daniel,
It appears you and Thierry are guilty to this:
d56f57ac969c7818986a0c78025740399e49f3a9
Could you please revert the vmwgfx-specific parts of that commit before
4.5 GA?
Thanks,
Thomas
On 03/04/2016 11:39 PM, Thomas Hellstrom wrote:
> Hi!
>
> Thanks for reporting. It appears that o
https://bugzilla.kernel.org/show_bug.cgi?id=113341
--- Comment #7 from Bernd Steinhauser ---
I tried to build LLVM/clang scm, but it failed (have to check why and if I can
get around that).
I've had several freezes over the last few weeks (most of them when I bisected
that other bug mentioned ab
https://bugzilla.kernel.org/show_bug.cgi?id=113891
Bug ID: 113891
Summary: [radeon] Display jitter
Product: Drivers
Version: 2.5
Kernel Version: 4.4.4
Hardware: x86-64
OS: Linux
Tree: Mainline
Stat
https://bugzilla.kernel.org/show_bug.cgi?id=113891
Jean Delvare changed:
What|Removed |Added
Regression|No |Yes
--
You are receiving this mail becau
Hi,
Jiri Slaby reported a kernel WARNING triggered by syzkaller. It can
be reliably reproduced via fbdev mmap access on bochs drm. The
warning looks like below:
WARNING: CPU: 3 PID: 29356 at ../drivers/gpu/drm/ttm/ttm_bo_vm.c:265
ttm_bo_vm_open+0x11a/0x180 [ttm]()
Modules linked in: ...
Suppor
On Tue, Feb 16, 2016 at 3:17 PM, Carlos Palminha
wrote:
> This patch set nukes all the dummy crtc mode_fixup implementations.
> (made on top of Daniel topic/drm-misc branch)
>
> Signed-off-by: Carlos Palminha
You should try to avoid mixing code style fixes with functional
changes but in case of
On 03/07/2016, 03:30 PM, Takashi Iwai wrote:
> Hi,
>
> Jiri Slaby reported a kernel WARNING triggered by syzkaller. It can
> be reliably reproduced via fbdev mmap access on bochs drm. The
> warning looks like below:
>
> WARNING: CPU: 3 PID: 29356 at ../drivers/gpu/drm/ttm/ttm_bo_vm.c:265
> ttm
Am 2016-03-03 um 16:05 schrieb Takashi Iwai:
> On Mon, 29 Feb 2016 15:39:53 +0100,
> Jani Nikula wrote:
>>
>> On Mon, 29 Feb 2016, Martin Kepplinger wrote:
>>> Am 2016-02-26 um 20:59 schrieb Takashi Iwai:
Sorry, Cc to Jani was missing mistakenly.
Please check this. It's a regressio
Hi Dave,
Resend of this pull request:
https://lists.freedesktop.org/archives/dri-devel/2016-February/101685.html
So I am requesting this to be pulled for v4.6.
The patches were reviewed here:
https://lists.freedesktop.org/archives/dri-devel/2016-February/101649.html
Best regards,
Jyri
The foll
On 03/04/2016 03:58 AM, Thierry Reding wrote:
> From: Thierry Reding
>
> Terje doesn't work on host1x anymore and doesn't have the time to help
> maintain the host1x and related drivers.
>
> Signed-off-by: Thierry Reding
> ---
> MAINTAINERS | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
On Mon, Mar 7, 2016 at 6:20 AM, Jörg-Volker Peetz wrote:
>
> This same problem with X does happen in 4.5-rc7. And removing the line
> introduced by patch b36e52c44ce6728824546d8b5f05b844cede96f1 makes X go again
> on
> my laptop.
Ok, so that's dbb17a21c131eca94eb31136eee9a7fe5aff00d9 in mainlin
Indeed, that hunk looks completely unrelated.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/91c7190a/attachment.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=113861
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #3 f
tcheroo. Does the attached patch
help?
Alex
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-selectively-call-drm_helper_hpd_irq_event.patch
Type: application/octet-stream
Size: 1087 bytes
Desc: 0001-drm-radeon-selectively-call-drm_helper_hpd_irq_event.patch
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/606d800f/attachment.obj>
Hi Dave,
the Etnaviv pull is mostly code cleanups courtesy of Russell King this
time, improving readability of certain parts of the driver a lot.
Notable changes:
- correctness fixes to the GPU cache flushing when switching execution
state and when powering down the GPU
- reduction of time spent
From: Thierry Reding
This partially reverts commit d56f57ac969c ("drm/gma500: Move to private
save/restore hooks") which removed these lines by mistake.
Reported-by: Sebastian Herbszt
Acked-by: Daniel Vetter
Signed-off-by: Thierry Reding
---
Hi Dave,
Daniel and I introduced this in v4.5-rc1,
https://bugzilla.kernel.org/show_bug.cgi?id=113861
--- Comment #4 from centuryplague at yandex.com ---
Created attachment 207961
--> https://bugzilla.kernel.org/attachment.cgi?id=207961&action=edit
dmesg for radeon xorg lockup upon startx
--
You are receiving this mail because:
You are watchin
https://bugzilla.kernel.org/show_bug.cgi?id=113861
--- Comment #5 from centuryplague at yandex.com ---
I've attached my dmesg run under 4.1.18 LTS. This was a boot under a regular
user (user doesn't matter, happens with root), and first command was "startx",
which polls eternally, the CTRL+C 500 t
Hi,
On Mon, Mar 7, 2016 at 12:37 AM, Mark yao wrote:
> On 2016å¹´03æ05æ¥ 20:39, Russell King - ARM Linux wrote:
>>
>> On Sat, Mar 05, 2016 at 12:11:16PM +, John Keeping wrote:
>>>
>>> On Fri, Mar 04, 2016 at 03:22:01PM -0800, Douglas Anderson wrote:
The drm_encoder_cleanup() was
Deucher, Alexander wrote on 03/07/16 17:44:
>> -Original Message-
>> From: linus971 at gmail.com [mailto:linus971 at gmail.com] On Behalf Of Linus
>> Torvalds
>> Sent: Monday, March 07, 2016 11:21 AM
>> To: Jörg-Volker Peetz; Dave Airlie; DRI mailing list
>> Cc: Greg KH; Linux Kernel Maili
Am Montag, 7. März 2016, 09:36:07 schrieb Doug Anderson:
> Hi,
>
> On Mon, Mar 7, 2016 at 12:37 AM, Mark yao wrote:
> > On 2016å¹´03æ05æ¥ 20:39, Russell King - ARM Linux wrote:
> >> On Sat, Mar 05, 2016 at 12:11:16PM +, John Keeping wrote:
> >>> On Fri, Mar 04, 2016 at 03:22:01PM -0800, D
On Mon, 07 Mar 2016, Martin Kepplinger wrote:
> This still isn't merged but still fixes a serious regression in v4.5.
> What's going on?
Bumps in the CI road. Now pushed to drm-intel-next-queued and
cherry-picked to drm-intel-fixes, en route to v4.5. Thanks for the
patch, review, and testing.
BR
> -Original Message-
> From: Jörg-Volker Peetz [mailto:jvpeetz at web.de]
> Sent: Monday, March 07, 2016 12:40 PM
> To: Deucher, Alexander; 'Linus Torvalds'; Dave Airlie; DRI mailing list
> Cc: Greg KH; Linux Kernel Mailing List; stable; lwn at lwn.net; Andrew Morton;
> Jiri Slaby
> Subjec
Hi,
On Mon, Mar 7, 2016 at 9:57 AM, Heiko Stübner wrote:
> Am Montag, 7. März 2016, 09:36:07 schrieb Doug Anderson:
>> Hi,
>>
>> On Mon, Mar 7, 2016 at 12:37 AM, Mark yao wrote:
>> > On 2016å¹´03æ05æ¥ 20:39, Russell King - ARM Linux wrote:
>> >> On Sat, Mar 05, 2016 at 12:11:16PM +, Joh
Hi Doug,
Am Montag, 7. März 2016, 10:49:53 schrieb Doug Anderson:
> On Mon, Mar 7, 2016 at 9:57 AM, Heiko Stübner wrote:
> > Am Montag, 7. März 2016, 09:36:07 schrieb Doug Anderson:
> >> Hi,
> >>
> >> On Mon, Mar 7, 2016 at 12:37 AM, Mark yao
wrote:
> >> > On 2016å¹´03æ05æ¥ 20:39, Russel
On Mon, Mar 07, 2016 at 07:56:18PM +0100, Heiko Stübner wrote:
> Hi Doug,
>
> Am Montag, 7. März 2016, 10:49:53 schrieb Doug Anderson:
> > On Mon, Mar 7, 2016 at 9:57 AM, Heiko Stübner wrote:
> > > Am Montag, 7. März 2016, 09:36:07 schrieb Doug Anderson:
> > >> Hi,
> > >>
> > >> On Mon, Mar
On Mon, Mar 7, 2016 at 6:06 PM, Thierry Reding
wrote:
> From: Thierry Reding
>
> This partially reverts commit d56f57ac969c ("drm/gma500: Move to private
> save/restore hooks") which removed these lines by mistake.
>
> Reported-by: Sebastian Herbszt
> Acked-by: Daniel Vetter
> Signed-off-by: T
Tested-by: Thomas Hellstrom
On 03/07/2016 06:06 PM, Thierry Reding wrote:
> From: Thierry Reding
>
> This partially reverts commit d56f57ac969c ("drm/gma500: Move to private
> save/restore hooks") which removed these lines by mistake.
>
> Reported-by: Sebastian Herbszt
> Acked-by: Daniel Vette
|--- |NOTABUG
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/edd715c7/attachment.html>
Hi,
Based on discussion around this patch:
https://lists.freedesktop.org/archives/dri-devel/2016-February/100685.html
I think the patch below should get into queued for v4.5 fixes as the
Beaglebone-Black display is currently broken in linux-master and
probably Armada is broken too. What should
The drm_encoder_cleanup() was missing both from the error path of
dw_hdmi_rockchip_bind(). This caused a crash when slub_debug was
enabled and we ended up deferring probe of HDMI at boot.
This call isn't needed from unbind() because if dw_hdmi_bind() returns
no error then it takes over the job of
The IMX dw_hdmi driver just called platform_set_drvdata() to get
your hopes up that maybe, somehow, you'd be able to retrieve the 'struct
imx_hdmi' from a pointer to the 'struct device'. You can't. When
we call dw_hdmi_bind() the main driver calls dev_set_drvdata(), which
clobbers our setting.
L
This fixes a few problems in the vop crtc cleanup (handling error
paths and cleanup upon exit):
* The vop_create_crtc() error path had an unsafe version of the
iterator used for iterating over all planes (though it was
destroying planes in the iterator so should have used the safe
version)
The drm_encoder_cleanup() was missing both from the error path of
dw_hdmi_imx_bind(). This caused a crash when slub_debug was
enabled and we ended up deferring probe of HDMI at boot.
This call isn't needed from unbind() because if dw_hdmi_bind() returns
no error then it takes over the job of free
The Rockchip dw_hdmi driver just called platform_set_drvdata() to get
your hopes up that maybe, somehow, you'd be able to retrieve the 'struct
rockchip_hdmi' from a pointer to the 'struct device'. You can't. When
we call dw_hdmi_bind() the main driver calls dev_set_drvdata(), which
clobbers our s
https://bugzilla.kernel.org/show_bug.cgi?id=113951
Bug ID: 113951
Summary: Kernel bug in AMDGPU
Product: Drivers
Version: 2.5
Kernel Version: 4.4.4
Hardware: x86-64
OS: Linux
Tree: Mainline
Status:
https://bugzilla.kernel.org/show_bug.cgi?id=113951
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 f
https://bugzilla.kernel.org/show_bug.cgi?id=113951
--- Comment #2 from Alex Deucher ---
Created attachment 208101
--> https://bugzilla.kernel.org/attachment.cgi?id=208101&action=edit
fix
This patch should fix it.
--
You are receiving this mail because:
You are watching the assignee of the bu
> -Original Message-
> From: Josh Poimboeuf [mailto:jpoimboe at redhat.com]
> Sent: Monday, March 07, 2016 6:10 PM
> To: Deucher, Alexander; Koenig, Christian
> Cc: dri-devel at lists.freedesktop.org; linux-kernel at vger.kernel.org;
> kbuild
> test robot; Ingo Molnar
> Subject: [PATCH] dr
On Sat, Mar 5, 2016 at 8:39 PM, Mario Kleiner
wrote:
> As observed on Apple iMac10,1, DCE-3.2, RV-730,
> link rate of 2.7 Ghz is not selected, because
> the args.v1.ucConfig flag setting for 2.7 Ghz
> gets overwritten by a following assignment of
> the transmitter to use.
>
> Move link rate setup
Daniel,
On Sun, Mar 6, 2016 at 8:29 AM, Daniel Vetter wrote:
> On Fri, Mar 04, 2016 at 03:43:53PM -0800, Douglas Anderson wrote:
>> On a system I'm doing development on I found a crash. The crawl looked
>> like:
>>
>> PC is at drm_atomic_add_affected_connectors+0x98/0xe8
>> ...
>> drm_atom
Hi,
On Mon, Mar 7, 2016 at 4:05 PM, Doug Anderson wrote:
> Daniel,
>
> On Sun, Mar 6, 2016 at 8:29 AM, Daniel Vetter wrote:
>> On Fri, Mar 04, 2016 at 03:43:53PM -0800, Douglas Anderson wrote:
>>> On a system I'm doing development on I found a crash. The crawl looked
>>> like:
>>>
>>> PC is a
Deucher, Alexander wrote on 03/07/16 19:07:
>> -Original Message-
>> From: Jörg-Volker Peetz [mailto:jvpeetz at web.de]
>> Sent: Monday, March 07, 2016 12:40 PM
>> To: Deucher, Alexander; 'Linus Torvalds'; Dave Airlie; DRI mailing list
>> Cc: Greg KH; Linux Kernel Mailing List; stable; lwn
This is a note to let you know that I have just added a patch titled
drm: Fix treatment of drm_vblank_offdelay in drm_vblank_on() (v2)
to the linux-4.2.y-queue branch of the 4.2.y-ckt extended stable tree
which can be found at:
http://kernel.ubuntu.com/git/ubuntu/linux.git/log/?h=linux-
4.2.8-ckt5 -stable review patch. If anyone has any objections, please let me
know.
---8<
From: Mario Kleiner
commit bb74fc1bf3072bd3ab4ed5f43afd287a63baf2d7 upstream.
drm_vblank_offdelay can have three different types of values:
<
Thomas Hellstrom wrote:
> Hi, Daniel,
>
> It appears you and Thierry are guilty to this:
>
> d56f57ac969c7818986a0c78025740399e49f3a9
Looks like Jongman Heo did also report this issue [1][2].
> Could you please revert the vmwgfx-specific parts of that commit before
> 4.5 GA?
>
> Thanks,
> Thom
When compiling the radeon driver on x86_64 with CONFIG_STACK_VALIDATION
enabled, objtool gives the following warnings:
drivers/gpu/drm/radeon/cik.o: warning: objtool:
cik_tiling_mode_table_init()+0x6ce: call without frame pointer save/setup
drivers/gpu/drm/radeon/cik.o: warning: objtool:
cik
;> page_fault+0x22/0x30
>> Mar 5 15:04:58 lutz kernel: [ 6995.240252] [] ?
>> radeon_fence_ref+0x10/0x50 [radeon]
>> Mar 5 15:04:58 lutz kernel: [ 6995.240268] []
>> radeon_sa_bo_new+0x302/0x590 [radeon]
>> Mar 5 15:04:58 lutz kernel: [ 6995.240270] [] ?
>> __kmalloc+0x66/0x1d0
>> Mar 5 15:04:58 lutz kernel: [ 6995.240283] [] ?
>> copy_from_user+0x9/0x10 [radeon]
>> Mar 5 15:04:58 lutz kernel: [ 6995.240296] []
>> radeon_ib_get+0x43/0xe0 [radeon]
>> Mar 5 15:04:58 lutz kernel: [ 6995.240309] []
>> radeon_cs_ioctl+0x201/0xac0 [radeon]
>> Mar 5 15:04:58 lutz kernel: [ 6995.240312] [] ?
>> idr_mark_full+0x52/0x70
>> Mar 5 15:04:58 lutz kernel: [ 6995.240320] []
>> drm_ioctl+0x401/0x580 [drm]
>> Mar 5 15:04:58 lutz kernel: [ 6995.240333] [] ?
>> radeon_cs_parser_init+0x470/0x470 [radeon]
>> Mar 5 15:04:58 lutz kernel: [ 6995.240335] [] ?
>> __do_page_fault+0x1cc/0x560
>> Mar 5 15:04:58 lutz kernel: [ 6995.240346] []
>> radeon_drm_ioctl+0x9/0x10 [radeon]
>> Mar 5 15:04:58 lutz kernel: [ 6995.240348] []
>> do_vfs_ioctl+0x81/0x4d0
>> Mar 5 15:04:58 lutz kernel: [ 6995.240351] [] ?
>> SyS_mmap_pgoff+0xd9/0x210
>> Mar 5 15:04:58 lutz kernel: [ 6995.240353] []
>> SyS_ioctl+0x91/0xa0
>> Mar 5 15:04:58 lutz kernel: [ 6995.240355] [] ?
>> do_page_fault+0xc/0x10
>> Mar 5 15:04:58 lutz kernel: [ 6995.240357] []
>> system_call_fastpath+0x16/0x1b
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
A non-text attachment was scrubbed...
Name: 0001-drm-radeon-guard-call-to-radeon_fence_ref-against-NU.patch
Type: text/x-patch
Size: 1447 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160307/ff63727a/attachment-0001.bin>
On 03/04/2016 01:32 PM, Eric Anholt wrote:
> VC4 is the GPU (display and 3D) present on the 283x.
> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
> b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
> +&hdmi {
> + hpd-gpios = <&gpio 46 GPIO_ACTIVE_LOW>;
> +};
Isn't that the same everywhere?
80 matches
Mail list logo
