https://bugs.freedesktop.org/show_bug.cgi?id=56139
--- Comment #42 from Alexandre Demers ---
Going fishing: Alex, you said you were unable to reproduce this bug with your
cayman device. Could it be related to the display connector? I'm using the DVI
connector from my card and it is connected to a
On 11/28/2012 05:39 AM, Stephen Warren wrote:
> On 11/27/2012 11:17 AM, Stephen Warren wrote:
>> On 11/26/2012 08:16 PM, Mark Zhang wrote:
>>> On 11/27/2012 06:37 AM, Stephen Warren wrote:
On 11/22/2012 12:37 PM, Thierry Reding wrote:
> Instead of using the stride derived from the display
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #8 from Alexandre Demers ---
In fact, Vladimir, could you edit your grub entry and see if there is "set
gfxpayload=keep". If so, change it to "set gfxpayload=text" or remove the line
completely. If it solves your boot issue, this woul
https://bugs.freedesktop.org/show_bug.cgi?id=57567
--- Comment #7 from Alexandre Demers ---
Could this be related to bug 56139? Description is similar to what is shown in
recorded boot process videos.
--
You are receiving this mail because:
You are the assignee for the bug.
Am Dienstag, den 27.11.2012, 14:39 -0700 schrieb Stephen Warren:
> > For your viewing pleasure (and playing with my new phone) :-)
> > http://www.youtube.com/watch?v=ZJxJnONz7DA
> >
> > The external monitor is 1920x1200 I believe.
>
> Jon Mayo says the corruption in the video is display (memory f
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #13 from Andre 2012-11-27 20:17:53 ---
I have to correct myself. The bug hits me again, this time only the HDMI output
was active.
Today after 4 hours the screen was blinking black and freezes except the mouse
was movable.
I'm r
HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121127/ffccb071/attachment-0001.html>
>
> Third would be having a firewall in 2D driver checking the stream and
> ensuring all registers that accept addresses are written by values
> derived from dmabufs. I haven't tried implementing this, but it'd
> involve a lookup table in kernel and CPU reading through the command
> stream. Offsets
At boot-up with newer kernels (at least v3.6.x, v3.7-rc) I always see
following on the bootup-display:
3.7-rcx: [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting
for forcewake old ack to clear.
3.6.x:[drm:__gen6_gt_force_wake_mt_get] *ERROR* Force wake wait timed out
It's an Ivy Bri
From: Alex Deucher
Hi Dave,
One last fix for 3.7 from Jerome. This fixes a display regression which results
in blank displays in some cases.
The following changes since commit 452f19201f35d20a1a6c9009acbcfa6799163c6a:
Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux
On Tue, 27 Nov 2012 17:29:36 +0100, J??rg Otte wrote:
> At boot-up with newer kernels (at least v3.6.x, v3.7-rc) I always see
> following on the bootup-display:
>
> 3.7-rcx: [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting
> for forcewake old ack to clear.
> 3.6.x:[drm:__gen6_gt_fo
On Tue, Nov 27, 2012 at 4:12 PM, wrote:
> From: Jerome Glisse
>
> This fix black screen on resume issue that some people are
> experiencing. There is a bug in the atombios code regarding
> pll/crtc mapping. The atombios code reverse the logic for
> the pll and crtc mapping.
>
> Signed-off-by: Je
From: Jerome Glisse
This fix black screen on resume issue that some people are
experiencing. There is a bug in the atombios code regarding
pll/crtc mapping. The atombios code reverse the logic for
the pll and crtc mapping.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/atombios_crtc.c
From: Jerome Glisse
To avoid kernel rejecting cs if we return different global name
for same bo keep track of global name and always return the same.
Seems to fix issue with suspend/resume failing and repeatly printing
following message :
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -
From: Jerome Glisse
There is a rare case, that seems to only happen accross suspend/resume
cycle, where a bo is associated with several different handle. This
lead to a deadlock in ttm buffer reservation path. This could only
happen with flinked(globaly exported) object. Userspace should not
reop
From: Jerome Glisse
This fix black screen on resume issue that some people are
experiencing. There is a bug in the atombios code regarding
pll/crtc mapping. The atombios code reverse the logic for
the pll and crtc mapping.
v2: DCE3 or DCE2 only have 2 crtc
Signed-off-by: Jerome Glisse
---
dri
e raw
EDID data, in addition to funcs like above?
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121127/dd2d3042/attachment-0001.pgp>
I don't really know how the kref can be used properly in this use case...
Tomi
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121127/4d1ae1de/attachment-0001.pgp>
On Tue, Nov 27, 2012 at 9:31 PM, Terje Bergström wrote:
> On 27.11.2012 12:37, Thierry Reding wrote:
>> But in that case it should be made mandatory at first until proper IOMMU
>> support is enabled on Tegra30. Then it can be checked at driver probe
>> time whether or not to enable the extra check
On 27.11.2012 13:47, Lucas Stach wrote:
> I guess we could change IOMMU address spaces for the graphics units
> depending on the active channel. This would still be a bit of a
> performance hit, because of the necessary TLB flushing and so on, but
> should be much better than checking the whole com
On 11/27/2012 11:17 AM, Stephen Warren wrote:
> On 11/26/2012 08:16 PM, Mark Zhang wrote:
>> On 11/27/2012 06:37 AM, Stephen Warren wrote:
>>> On 11/22/2012 12:37 PM, Thierry Reding wrote:
Instead of using the stride derived from the display mode, use the pitch
associated with the current
From: Alex Deucher
Hi Dave,
One last fix for 3.7 from Jerome. This fixes a display regression which results
in blank displays in some cases.
The following changes since commit 452f19201f35d20a1a6c9009acbcfa6799163c6a:
Merge branch 'drm-fixes-3.7' of git://people.freedesktop.org/~agd5f/linux
From: Jerome Glisse
To avoid kernel rejecting cs if we return different global name
for same bo keep track of global name and always return the same.
Seems to fix issue with suspend/resume failing and repeatly printing
following message :
[drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -
Am Dienstag, den 27.11.2012, 14:39 -0700 schrieb Stephen Warren:
> > For your viewing pleasure (and playing with my new phone) :-)
> > http://www.youtube.com/watch?v=ZJxJnONz7DA
> >
> > The external monitor is 1920x1200 I believe.
>
> Jon Mayo says the corruption in the video is display (memory f
On 11/27/2012 11:17 AM, Stephen Warren wrote:
> On 11/26/2012 08:16 PM, Mark Zhang wrote:
>> On 11/27/2012 06:37 AM, Stephen Warren wrote:
>>> On 11/22/2012 12:37 PM, Thierry Reding wrote:
Instead of using the stride derived from the display mode, use the pitch
associated with the current
On Tue, 2012-11-27 at 09:04 +0530, Sachin Kamat wrote:
> ping
>
> On 20 November 2012 11:23, Sachin Kamat wrote:
> > nouveau_ttm.h was included twice.
I've queued it in my tree, thanks!
Ben.
> >
> > Signed-off-by: Sachin Kamat
> > ---
> > drivers/gpu/drm/nouveau/nouveau_drm.c |2 --
> > 1
Op 22-11-12 21:29, Thomas Hellstrom schreef:
> On 11/22/2012 04:51 PM, Maarten Lankhorst wrote:
>> Op 21-11-12 14:27, Thomas Hellstrom schreef:
>>> On 11/21/2012 02:12 PM, Maarten Lankhorst wrote:
Op 21-11-12 13:42, Thomas Hellstrom schreef:
> On 11/21/2012 12:38 PM, Maarten Lankhorst wrot
On Tue, Nov 27, 2012 at 4:12 PM, wrote:
> From: Jerome Glisse
>
> This fix black screen on resume issue that some people are
> experiencing. There is a bug in the atombios code regarding
> pll/crtc mapping. The atombios code reverse the logic for
> the pll and crtc mapping.
>
> Signed-off-by: Je
On 27.11.2012 12:37, Thierry Reding wrote:
> But in that case it should be made mandatory at first until proper IOMMU
> support is enabled on Tegra30. Then it can be checked at driver probe
> time whether or not to enable the extra checks. That way we don't need a
> special Kconfig option and we st
From: Jerome Glisse
This fix black screen on resume issue that some people are
experiencing. There is a bug in the atombios code regarding
pll/crtc mapping. The atombios code reverse the logic for
the pll and crtc mapping.
Signed-off-by: Jerome Glisse
---
drivers/gpu/drm/radeon/atombios_crtc.c
From: Jerome Glisse
There is a rare case, that seems to only happen accross suspend/resume
cycle, where a bo is associated with several different handle. This
lead to a deadlock in ttm buffer reservation path. This could only
happen with flinked(globaly exported) object. Userspace should not
reop
From: Jerome Glisse
This fix black screen on resume issue that some people are
experiencing. There is a bug in the atombios code regarding
pll/crtc mapping. The atombios code reverse the logic for
the pll and crtc mapping.
v2: DCE3 or DCE2 only have 2 crtc
Signed-off-by: Jerome Glisse
---
dri
On Mon, Nov 26, 2012 at 02:19:08PM +0100, Terje Bergstrom wrote:
> +void nvhost_intr_stop(struct nvhost_intr *intr)
> +{
> + unsigned int id;
> + struct nvhost_intr_syncpt *syncpt;
> + u32 nb_pts = nvhost_syncpt_nb_pts(&intr_to_dev(intr)->syncpt);
> +
> + mutex_lock(&intr->m
On Mon, Nov 26, 2012 at 02:19:07PM +0100, Terje Bergstrom wrote:
> +
> +struct nvhost_chip_support *nvhost_chip_ops;
should be static?
> +static int __devinit nvhost_alloc_resources(struct nvhost_master *host)
> +{
> + int err;
> +
> + err = nvhost_init_chip_support(host);
> + i
Am Dienstag, den 27.11.2012, 13:31 +0200 schrieb Terje Bergstr?m:
> On 27.11.2012 12:37, Thierry Reding wrote:
> > But in that case it should be made mandatory at first until proper IOMMU
> > support is enabled on Tegra30. Then it can be checked at driver probe
> > time whether or not to enable the
https://bugzilla.kernel.org/show_bug.cgi?id=47481
--- Comment #13 from Andre 2012-11-27 20:17:53 ---
I have to correct myself. The bug hits me again, this time only the HDMI output
was active.
Today after 4 hours the screen was blinking black and freezes except the mouse
was movable.
I'm r
hat case it should be made mandatory at first until proper IOMMU
support is enabled on Tegra30. Then it can be checked at driver probe
time whether or not to enable the extra checks. That way we don't need a
special Kconfig option and we still get all the security that we need,
right?
Thierry
bla-0.5)*100.0)));
works fine
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121127/439f074a/attachment.html>
Am Dienstag, den 27.11.2012, 10:45 +0200 schrieb Terje Bergstr?m:
> On 27.11.2012 10:32, Dave Airlie wrote:
> > On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergstr?m
> > wrote:
> >> Thanks for the pointer, I looked at exynos code. It indeed checks the
> >> registers written to, but it doesn't prevent
On 11/26/2012 08:16 PM, Mark Zhang wrote:
> On 11/27/2012 06:37 AM, Stephen Warren wrote:
>> On 11/22/2012 12:37 PM, Thierry Reding wrote:
>>> Instead of using the stride derived from the display mode, use the pitch
>>> associated with the currently active framebuffer. This fixes a bug where
>>> th
On 11/27/2012 06:37 AM, Stephen Warren wrote:
> On 11/22/2012 12:37 PM, Thierry Reding wrote:
>> Instead of using the stride derived from the display mode, use the pitch
>> associated with the currently active framebuffer. This fixes a bug where
>> the LCD display content would be skewed when enabl
On 27.11.2012 10:32, Dave Airlie wrote:
> On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergstr?m
> wrote:
>> Thanks for the pointer, I looked at exynos code. It indeed checks the
>> registers written to, but it doesn't prevent overrun by checking sizes
>> of buffers and compare against requests.
> They
On 11/26/2012 08:16 PM, Mark Zhang wrote:
> On 11/27/2012 06:37 AM, Stephen Warren wrote:
>> On 11/22/2012 12:37 PM, Thierry Reding wrote:
>>> Instead of using the stride derived from the display mode, use the pitch
>>> associated with the currently active framebuffer. This fixes a bug where
>>> th
On 11/26/2012 11:33 PM, Terje Bergstr?m wrote:
> On 27.11.2012 01:39, Stephen Warren wrote:
>> Clock names shouldn't be passed in platform data; instead, clk_get()
>> should be passed the device object and device-relative (i.e. not global)
>> clock name. I expect if the driver is fixed to make this
On 27.11.2012 09:33, Dave Airlie wrote:
>> Third would be having a firewall in 2D driver checking the stream and
>> ensuring all registers that accept addresses are written by values
>> derived from dmabufs. I haven't tried implementing this, but it'd
>> involve a lookup table in kernel and CPU rea
https://bugs.freedesktop.org/show_bug.cgi?id=56659
runetmem...@gmail.com changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|NOTAB
ri-devel/attachments/20121127/2ae15e66/attachment.html>
On 11/26/2012 11:33 PM, Terje Bergström wrote:
> On 27.11.2012 01:39, Stephen Warren wrote:
>> Clock names shouldn't be passed in platform data; instead, clk_get()
>> should be passed the device object and device-relative (i.e. not global)
>> clock name. I expect if the driver is fixed to make this
On 27 November 2012 09:09, Ben Skeggs wrote:
> On Tue, 2012-11-27 at 09:04 +0530, Sachin Kamat wrote:
>> ping
>>
>> On 20 November 2012 11:23, Sachin Kamat wrote:
>> > nouveau_ttm.h was included twice.
> I've queued it in my tree, thanks!
Thanks Ben. There is also another patch for which I have
ping..
On 20 November 2012 11:35, Sachin Kamat wrote:
> core/device.h was included twice.
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/nouveau/core/subdev/device/base.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/d
ping
On 20 November 2012 11:23, Sachin Kamat wrote:
> nouveau_ttm.h was included twice.
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/nouveau/nouveau_drm.c |2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers
On 27.11.2012 00:15, Dave Airlie wrote:
>> static int tegra_drm_open(struct drm_device *drm, struct drm_file *filp)
>> {
>> - return 0;
>> + struct tegra_drm_fpriv *fpriv;
>> + int err = 0;
>> +
>> + fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
>> + if (!fpriv)
>> +
On Tue, 27 Nov 2012 17:29:36 +0100, Jörg Otte wrote:
> At boot-up with newer kernels (at least v3.6.x, v3.7-rc) I always see
> following on the bootup-display:
>
> 3.7-rcx: [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting
> for forcewake old ack to clear.
> 3.6.x:[drm:__gen6_gt_fo
On 27.11.2012 01:39, Stephen Warren wrote:
> Clock names shouldn't be passed in platform data; instead, clk_get()
> should be passed the device object and device-relative (i.e. not global)
> clock name. I expect if the driver is fixed to make this change, the
> changes to tegra*_clocks_data.c won't
On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergstr?m
wrote:
> On 27.11.2012 09:33, Dave Airlie wrote:
>>> Third would be having a firewall in 2D driver checking the stream and
>>> ensuring all registers that accept addresses are written by values
>>> derived from dmabufs. I haven't tried implementing
> static int tegra_drm_open(struct drm_device *drm, struct drm_file *filp)
> {
> - return 0;
> + struct tegra_drm_fpriv *fpriv;
> + int err = 0;
> +
> + fpriv = kzalloc(sizeof(*fpriv), GFP_KERNEL);
> + if (!fpriv)
> + return -ENOMEM;
> +
> + INIT_
On 11/16/2012 01:14 PM, Jerome Glisse wrote:
On Fri, Nov 16, 2012 at 12:05:40PM -0800, Aaron Plattner wrote:
At the suggestion of a few drm developers, I'm looking at abstracting the buffer
sharing mechanism away from the individual drm drivers and treating it as a
low-level interface that kerne
On 11/16/2012 01:14 PM, Jerome Glisse wrote:
> On Fri, Nov 16, 2012 at 12:05:40PM -0800, Aaron Plattner wrote:
>> At the suggestion of a few drm developers, I'm looking at abstracting the
>> buffer
>> sharing mechanism away from the individual drm drivers and treating it as a
>> low-level interfac
On 27.11.2012 13:47, Lucas Stach wrote:
> I guess we could change IOMMU address spaces for the graphics units
> depending on the active channel. This would still be a bit of a
> performance hit, because of the necessary TLB flushing and so on, but
> should be much better than checking the whole com
Op 22-11-12 21:29, Thomas Hellstrom schreef:
> On 11/22/2012 04:51 PM, Maarten Lankhorst wrote:
>> Op 21-11-12 14:27, Thomas Hellstrom schreef:
>>> On 11/21/2012 02:12 PM, Maarten Lankhorst wrote:
Op 21-11-12 13:42, Thomas Hellstrom schreef:
> On 11/21/2012 12:38 PM, Maarten Lankhorst wrot
Am Dienstag, den 27.11.2012, 13:31 +0200 schrieb Terje Bergström:
> On 27.11.2012 12:37, Thierry Reding wrote:
> > But in that case it should be made mandatory at first until proper IOMMU
> > support is enabled on Tegra30. Then it can be checked at driver probe
> > time whether or not to enable the
On Mon, Nov 26, 2012 at 02:19:08PM +0100, Terje Bergstrom wrote:
> +void nvhost_intr_stop(struct nvhost_intr *intr)
> +{
> + unsigned int id;
> + struct nvhost_intr_syncpt *syncpt;
> + u32 nb_pts = nvhost_syncpt_nb_pts(&intr_to_dev(intr)->syncpt);
> +
> + mutex_lock(&intr->m
On Mon, Nov 26, 2012 at 02:19:07PM +0100, Terje Bergstrom wrote:
> +
> +struct nvhost_chip_support *nvhost_chip_ops;
should be static?
> +static int __devinit nvhost_alloc_resources(struct nvhost_master *host)
> +{
> + int err;
> +
> + err = nvhost_init_chip_support(host);
> + i
On 27.11.2012 12:37, Thierry Reding wrote:
> But in that case it should be made mandatory at first until proper IOMMU
> support is enabled on Tegra30. Then it can be checked at driver probe
> time whether or not to enable the extra checks. That way we don't need a
> special Kconfig option and we st
https://bugs.freedesktop.org/show_bug.cgi?id=51421
Golubev Yaroslav changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Tue, Nov 27, 2012 at 11:22:56AM +0100, Lucas Stach wrote:
> Am Dienstag, den 27.11.2012, 10:45 +0200 schrieb Terje Bergström:
> > On 27.11.2012 10:32, Dave Airlie wrote:
> > > On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergström
> > > wrote:
> > >> Thanks for the pointer, I looked at exynos code.
Am Dienstag, den 27.11.2012, 10:45 +0200 schrieb Terje Bergström:
> On 27.11.2012 10:32, Dave Airlie wrote:
> > On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergström
> > wrote:
> >> Thanks for the pointer, I looked at exynos code. It indeed checks the
> >> registers written to, but it doesn't prevent
On 27 November 2012 09:09, Ben Skeggs wrote:
> On Tue, 2012-11-27 at 09:04 +0530, Sachin Kamat wrote:
>> ping
>>
>> On 20 November 2012 11:23, Sachin Kamat wrote:
>> > nouveau_ttm.h was included twice.
> I've queued it in my tree, thanks!
Thanks Ben. There is also another patch for which I have
ping..
On 20 November 2012 11:35, Sachin Kamat wrote:
> core/device.h was included twice.
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/nouveau/core/subdev/device/base.c |1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/subdev/d
ping
On 20 November 2012 11:23, Sachin Kamat wrote:
> nouveau_ttm.h was included twice.
>
> Signed-off-by: Sachin Kamat
> ---
> drivers/gpu/drm/nouveau/nouveau_drm.c |2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
> b/drivers
https://bugs.freedesktop.org/show_bug.cgi?id=57531
Christian König changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 27.11.2012 10:32, Dave Airlie wrote:
> On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergström
> wrote:
>> Thanks for the pointer, I looked at exynos code. It indeed checks the
>> registers written to, but it doesn't prevent overrun by checking sizes
>> of buffers and compare against requests.
> They
On Tue, Nov 27, 2012 at 8:16 AM, Terje Bergström wrote:
> On 27.11.2012 09:33, Dave Airlie wrote:
>>> Third would be having a firewall in 2D driver checking the stream and
>>> ensuring all registers that accept addresses are written by values
>>> derived from dmabufs. I haven't tried implementing
On 27.11.2012 09:33, Dave Airlie wrote:
>> Third would be having a firewall in 2D driver checking the stream and
>> ensuring all registers that accept addresses are written by values
>> derived from dmabufs. I haven't tried implementing this, but it'd
>> involve a lookup table in kernel and CPU rea
74 matches
Mail list logo
